Hi,I configured the SharePoint logs to output to the E: drive on the SharePoint server. I have noticed that every minute a HOSTS.2010.01.18.14.53.20.92 file is generated in the folder for logs. Each "HOSTS" file is 1K in size. In one week about 14,500 of the "HOSTS" files were created in this folder.Also a log file is created everyday (sometimes 2 log files) that is over 3GB's in size.I have set up a script that deletes the "HOSTS" file and the log files.Why are these "HOSTS" files being created? How do I prevent such huge amount of files?How do I prevent large log files?

For the log files, if you go to Central Admin -> Operations -> Diagnostic Logging, you can set up your Event throttling (we only log errors right now), as well as the number of log files to keep (we keep 5, and use each one for 30 minutes) As for the hosts files, I'm looking for that resolution as well. We've been running MOSS 2007 for about 10 months, and actually ran out of server space over the weekend due to this issue. I just deleted over a quarter million of these files. I had to do it on both or production and development servers. Quite annoying, and would love to know hot to stop these from cluttering up our server.

Hi wexford, Does search work fine within your SharePoint farm? If Office SharePoint Server Search Service is down on your SharePoint farm, you need to configure Search Service again.When you select this option “Central Admin -> Operations -> Services on Server -> Office SharePoint Server Search Service Settings -> Use a dedicated web front end for crawling”, the Index server adds hosts file in “C:\WINDOWS\system32\drivers\etc” for all of the hostnames for all web apps and the IP address of the WFE. I think HOSTS file in log is the backup file for the above. If you select this option, you can switch to “Use all web front ends for crawling” then check the result. If this doesn’t help, Process Monitor may help to monitor who and how this file created. After this, you can perform further troubleshooting steps such as to check whether that user has appropriate permission to “C:\WINDOWS\system32\drivers\etc” folder. Hope it helps.Lily Wu

MProper and Lily Wu,Thanks for replying.Thanks for the tips on the log files. I have reconfigured for 10 log files and 144 minutes each.Lily,Yes search works fine in the Farm. I see an access denied “C:\WINDOWS\system32\drivers\etc” error 6482 in the event log on the SharePoint server hosting Central Admin. The HOSTS file in “C:\WINDOWS\system32\drivers\etc” is also read-only. Every time that error occurs in the event log we also see the HOSTS.2010.01.18.14.53.20.92 file written to the E: drive.What is also interesting about the "HOSTS" file that is written to the log is that it is always Date Modified stamp of 11/08/2008 11:18 even though it is created every minute of every day. So you are correct in that it is a backup of the real HOSTS file.After further investigation we found that a process in SharePoint modifies the HOSTS file and rewrites (incorrectly) the IP addresses of the SharePoint servers in that HOSTS file. This caused some of the servers in the Farm to become inaccessible because the IP address was incorrectly rewritten by SharePoint to the HOSTS file.We know this because the server was built with an IP address and then moved into our Data Centre. (This would happen regularly in IT departments where a server is imaged with an OS build and then move to site.) The data centre IP address was different to the original IP address that the server was built with. When SharePoint rewrites the HOSTS file it incorrectly puts that original IP address instead of the new data centre IP address.I think it has that IP address in the SQL database somewhere and writes it out to the HOSTS file.I don't know how to fix it because if I make the HOSTS file readable again then server becomes inaccessible after the HOSTS file is rewritten.

Since posting this first I have tried to reconfigure the indexing settings in the SharePoint Farm. We use a dedicated indexing server and it appears that the HOSTS file is overwritten by SharePoint every minute (this is what causes the HOSTS file to be backed up to the log folder). The issue is that when using a dedicated WFE for indexing that INCORRECT ip addresses are written to the HOSTS file by SharePoint. This is a bug. Both of these articles: http://www.sharepointbuddy.com/2009/05/configuring-dedicated-front-end-web.html http://technet.microsoft.com/en-us/library/cc261810.aspx it says "in some cases, incorrect ip addresses are written to the hosts file". In my experience it is in ALL CASES if a dedicated WFE is configured for indexing. The technet article should be amended. In my case neither of the cases outlined in the articles are true: *network card does not have multiple ip addresses assigned *server farm is not using network load balancing The incorrect IP address are still written to the HOSTS file. For our main WFE we get 192.168.10.20 when it should be 192.168.10.10. The 192.168.10.20 is actually the IP address of the indexing server. To stop this making our WFE inaccessible we have had to make the HOSTS file read-only. Doing this makes the Application log present the following error every minute: ******* Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (5bfe6b3f-9619-4cb9-b27d-207000108ef5). Reason: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied. ******* Why does it write the wrong IP addresses?

Seems like "WSS_ADMIN_WPG" does not have permissions on HOSTS file. Make sure WSS_ADMIN_WPG has following permissions on HOSTS file. If not, grant these permissions manually. Traverse Folder / Execute File List Folder / Read Data Read Attributes Read Extended Attributes Create Files / Write Data Read Permissions Hope it helps....