January 2008 - Posts

On Monday January, 28th my SpringPoint colleague Scott Brenton and I will be co-presenting on Visual Studio 2008 RTM at the Tulsa Developers .NET User Group.  Our presentation is a Tips and Tricks session with a little something for everyone.  We will have tips for beginners and seasoned pros.  The presentation will begin with and intro of Visual Studio 2008 and by the conclusions attendees should understand the benefits of upgrading.  Furthermore, the Visual Studio 2008 environment should not feel completely foreign.  Our presentation will include such topics as:

  • Keyboard Short Cuts
  • Refactoring
  • Auto-Implemented Properties
  • VSTO Projects
  • JavaScipt Intellisense and Debugging
  • Project Navigation
  • Source Server
  • MS Build and Build Targeting
  • Solution Upgrading

Problem:

We just installed a Medium MOSS 07 Farm.  The Farm has two front end webs and a dedicated indexing server.  The two front end webs are configured to execute search queries.  The SSP Admin site was loading and a search content source could be selected.  However, after specify a schedule for the selected content source and clicking ok an access denied error would appear on the schedule management window.  The message said "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))."  The MOSS Error Logs captured the following nastiness:

w3wp.exe (0x0B5C) 0x0E48 Search Server Common MS Search Administration 86zc High Exception caught in Search Admin web-service proxy (client). System.Web.Services.Protocols.SoapException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at Microsoft.Office.Server.Search.Administration.SearchWebServiceProxy.RunWithSoapExceptionHandling[T](String methodName, Object[] parameters)

... and more

Resolution:

The log and error message hinted at some kind of permission issue.  We also noticed that the logs specifically implicated our third server in the farm, our dedicated index server.  After some searching on MSDN and TechNet we learned that the C:\Windows\Tasks directory was not configured properly.  The local WSS_WPG machine needed to be given read and write permissions to the C:\Windows\Tasks directory.  Once we had assigned appropriate permissions and completed an IISReset form good measures we were able to save a schedule. 

For more info review this MS KB posting: http://support.microsoft.com/kb/926959