Alpesh Nakar's Blog

In our production setup, we experienced this issue when trying to access the Shared Service Provider Admin Web site. In a different environment, the SharePoint Configuration Wizard failed and it was same error that needed to be fixed.

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category:    Office Server Shared Services
Event ID:    6482
Date:        26/02/2008
Time:        2:00:22 PM
User:        N/A
Computer:    xxxx
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (03614600-d68b-43e2-9705-36d06c36b2f7).

Reason: Access to the path ‘C:\WINDOWS\system32\drivers\etc\HOSTS’ is denied.

Techinal Support Details:
System.UnauthorizedAccessException: Access to the path ‘C:\WINDOWS\system32\drivers\etc\HOSTS’ is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append)
at System.IO.FileInfo.CreateText()
at Microsoft.Search.Administration.Security.HOSTSFile.CleanupDedicatedGathering(Hashtable HOSTSFileMappings, StringBuilder HOSTSComments, IEnumerable obsoleteHosts, String dedicatedName, Boolean isDirty)
at Microsoft.Search.Administration.Security.HOSTSFile.ConfigureDedicatedGathering(SearchServiceInstance searchServiceInstance, SPServer dedicatedWebFrontEndServer, IList`1 previousWebApplicationHostNames)
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.SynchronizeDefaultContentSource(IDictionary applications)
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

Resolution

1. Check if hosts file exist in c:\WINDOWS\system32\drivers\etc (It should, but in our version of the build, it didn’t exist)
2. Assign these permissions to the etc folder
   1. %computername%\WSS_Admin_WPG should have permissions as in the image
   2. %computername%\WSS_WPG should have permissions as in the image

These should be on all the servers in the farm.

When using Internet Explorer (version does not matter) to browse SharePoint Portal Server, Windows SharePoint Services or Office SharePoint Server 2007 – intranets or launch Office application files like word document, excel files I get logon prompts, especially having Office 2007 installed on my Vista Enterprise edition.

I read on SharePoint Team Blog on how to fix this issue. However, in the past I have used this technique to resolve this and it does not matter if its Vista/Office 2007 combination, hence this post.

In most cases, pressing escape key opens the Office application files. It is very annoying to do this every time though. To get around this issue, I use the following workaround as illustrated in the picture.

I have also used this workaround on Windows Server 2003 Enterprise Edition for launching MOSS 2007 sites. This is illustrated in the video. My first attempt at screencast (minus the voice over)

Video Link – Double Click on Video for Full Screen View.

Follow the steps outlined to resolved DCOM errors on Windows 2003 Servers running Microsoft Windows SharePoint Services v3.

Steps for IIS WAMREG admin service

Step 1: Click Start, Click Run, type dcomcnfg and click ok

Step 2: Expand Component Services / Computers / My Computer / DCOM Config

Step 3: Right click IIS WAMREG admin Service and choose Properties

Step 4: Click the Security tag

Step 5: Click Edit under Launch and Activation Permissions

Step 6: In the Permissions for UserName list unselect the Remote Launch and Remote Activation check box for Network Service

Step 7: In the Permissions for UserName list unselect the Remote Launch and Remote Activation check box for WSS_ADMIN_WPG

Step 8: In the Permissions for UserName list unselect the Remote Launch and Remote Activation check box for WSS_WPG

Steps for netman admin service

Step 1: Right click netman admin Service and choose Properties

Step 2: Click the Security tag

Step 3: In the Permissions for UserName list unselect the Remote Launch and Remote Activation check box for Network Service

Step 4: In the Permissions for UserName list unselect the Remote Launch and Remote Activation check box for WSS_ADMIN_WPG

Step 5: In the Permissions for UserName list unselect the Remote Launch and Remote Activation check box for WSS_ WPG

Step 6: Close the Component Services Windows

Step 7: Click Start, Click Run, type iisreset and click ok

I have come across an issue when using SharePoint (SPS and WSS) with Windows XP.

Yes, we are not even into enterprise wide planning for SharePoint 2007 as yet. Wssv3 is a different story, which you may have been following through my posts and will continue to over coming months…

Coming back to Wssv2 issue/Project Server 2003. On our network we have a password policy, so users are required to
change their password every 60 days.

I have noticed a few times now that some users, after changing their network password, are prompted by SharePoint (SPS and WSS) for their credentials. After entering the information 3 times they are given an “Access Denied” error. This was also then performing an AD “Account Lockout” on their account and preventing them from accessing their email and other network services.

If the user logged onto a different machine with their new network password there would be no problem accessing SharePoint and no prompt was displayed, which meant the problem was a local issue.

It seemed as though the old username and password was being cached somewhere. This issue only seemed to affect some users and not everyone who changed their password.

After much investigating I found the cause and a workaround to resolve the issue.

Cause:

What seemed to happen was it was storing the old information in the
Password list under the Manage Passwords section under “User Accounts”.
(Start > Settings > Control Panel > User Accounts)

If a user who had ever tried accessing an Area or document library in
SharePoint where they didn’t have permission, they were getting
prompted for their credentials, and the information was being stored in
this list.

When the user changed their network password after 45 days, then went
to log back on to SharePoint, it was still recognising their old
credentials from the cached password list, so when they typed their new
password it wasn’t authenticating, because the passwords matched.

Resolution:

1. Click “Start” > “Settings” > “Control Panel”
2. Double click “User Accounts”
3. Click on the “Advanced” tab
4. In the “Passwords and .NET Passports” area click “Manage Passwords”
5. Remove everything there.

Also, delete everything in this directory:

C:Documents and SettingsYOURUSERNAMEApplication DataMicrosoftCredentials

and everything in this directory:

C:Documents and SettingsYOURUSERNAMELocal SettingsApplication DataMicrosoftCredentials

This is going to be short and sweet. But to get this solution, I have burned many Virtual Machines and our developer rebuilt real servers atleast 7 times. It is a different story that the Windows Server 2003 build was automated. However after every build was given to me, I used to run the setup and the configuration wizard would fail on Step 5 of Step 10.

No help from newsgroups, Microsoft or anyone. Atleast this will help someone.

This solution worked for me in our environment, it should work for you. Please consult your system administrators to make sure, this solution fits your environment. I was given a go ahead. I am not responsible for what you do to make Windows SharePoint Services v3 work in your environment on your domain controllers.

This is the error, after the Configuration Wizard failed on Step 5.

An exception of type System.Runtime.InteropServices.COMException was thrown. Additional exception information: Class not registered

I have tried so many combinations of security permissions that I have no words to express my frustration! Well in the end, it works and has been approved by the system administrators. I don’t know if it is compromising security, but Windows SharePoint Services V3 installs on the DC.

Lets not delve into the security groups, just grab this information (which you have been wanting to know):

C: Local Service (Read& Execute List Folder Contents Read)
Network Service (Modify Read& Execute List Folder Contents Read Write)
WSS_Admin_WPG(FC)

C:Windows Temp Network Service Full Control
WSS_Admin_WPG(FC)
WSS_WPG (Read& Execute List Folder Contents Read)

Apply these permissions to C: drive and you are done. No more errors for Step 5!

Whew!

Next UP: Moving Windows Internal Database using a script (batch file)