Hello! Our SP 3.0 logging and Usage Analysis Processing were used to working ok. After we moved database to another server for disk space reason, there is no new log file generated from the date of db moving. The logging settings and Usage Analysis setting are still the same. We tried disable / re-enable logging, it didn't help. From system log, I saw following errors, and then granted the service account all access to "IIS WAMREG admin Service" DCOM Config based on document found in MSDN. It still not help "The application-specific permission settings do not grant Local Activation permission for the COM Server application ..." Could someone please share info/knowledge on similar issue and solutions? I really appreciate it! Thank you in advance! John

did you reset the IIS after grant the services account to access? any error in ULS logs after made changes in the CA. hope this will work thanks -wsi am at SharePoint administrator

Thank you for your response! I reset IIS and still not seeing new log file generate. The DCOM error no longer appear though. And advice on anything else need to look into? Thanks again! John

Hi, 1. Make sure the logs path is valid and accessible for the farm account in the new server. 2. Make sure all timer jobs related with logs are working fine. Hope it is helpful!Seven

did you try to specify Verbose log level? In such cases much more records are added in log then by default. In order to do it go to Central Administration >Operations > Diagnostic logging. Select category = All, Least critical event to report to the event log = Error, Least critical event to report to the trace log = Verbose. And make iisresetBlog - http://sadomovalex.blogspot.com Codeplex - http://camlex.codeplex.com

Thank you! It's quite simple structure - one app server where sharepoint reside and one SQL database server. Logs path is on app server, before and after the db server moving. It should not a cause I guess. The timer jobs are running daily and always reported success. It's just having no new log files to process.

Actually, the diagnostic logging working fine, it generate trace log files normally. The problem is only for usage analysis logging, it's enabled, but no new log file generated after the database server moved. Would you think verbose log level setting in diagnostic log could affect usage analysis logging as well? Thank you for your kind response!

Hello John, Please check if permission of the WSS_ADMIN_WPG and the WSS_WPG to the log folder is set properly? Verify that the SharePoint Timer Service is started. To do this, follow these steps: Click Start, point to Administrative Tools, and then click Services. Determine whether the SharePoint Timer Service is started. If it is not started, start it. To do this, right-click SharePoint Timer Service, and then click Start. Also check if your Tracing service is started. Assign the WSS_ADMIN_WPG and the WSS_WPG group at least Read, Write, and Update permissions to the folder that stores the log files. To do this, follow these steps: Start Windows Explorer, locate the folder, right-click it, and then click Sharing and Security. Click the Security tab. Add the WSS_ADMIN_WPG and the WSS_WPG group if the group is not already listed. To do this, click Add, type WSS_ADMIN_WPG and the WSS_WPG in the Enter the object names to select box, click Check Names to verify the name, and then click OK. In the Permissions for WSS_ADMIN_WPG and the WSS_WPG box, click to select the check boxes next to the permissions that you want to assign to the group under Allow, and then click OK. try the following (make sure you are in the home folder for stsadm, or specify the full path to the executable): stsadm -o getproperty -propertyname job-usage-analysis -url http://<yoursite> if this returns NO, it means the flag isn't set. you can set it: stsadm -o setproperty -propertyname job-usage-analysis -propertyvalue "daily between 00:00:00 and 00:01:00" -url http://<yoursite> Thanks , Manas Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread."