I realize that this won't be a simple answer so I'm just looking for a few ideas. The question is, how do I determine if the configuration DB is corrupt. I need to be absolutely (or as close to it as computers will allow us) sure before I make the recommendation to go ahead rebuilding the farm. Environment: MOSS '07 SP2, SQL '05 SP 3.5, 4 WFE's.At this time, we're having a few very odd issues, none of which I can complete pinpoint a cause of. My thoughts are that since they seem unrelated and 2 of them spread across any webapp in the farm, that it must point back to the config DB as it's the only thing connecting them. Symptoms: Across Farm1) In IIS, if I change the _layouts virtual directory to point at copy of the layouts folder, not the default 12 hive, it will be reset back the default 12 hive when OK is clicked from the authentication providers screen inside Central Admin. 2) We recieve an error when going to page settings for any page stored at the root level of a site using the publishing template. This even happens on a freshly created webapp and sitecollection. It works fine for any publishing feature subsite, ie News. On 1 WebApplication3) When I hit OK in the Authentication Providers screen, connection strings and membership provider information in the web.config is overrwitten. This one has been a thorn in my side for a while now, and I have just recently found entries in the objects table in the config database similar to the incorrect lines. I believe they are being written because of a "WebConfigChanges" line in that table. As well, I believe they were put there during the installation of the ECTS and not removed when the solution was retracted and removed.If anyone has any ideas of how I could pinpoint this back to the config DB - or you believe this is something completely different, I'm all ears.Thank you in advance,-Bill

For No2 what is error message that you are getting, Did u check the event log or Sp Log ? Do you a custom Masterpage or Content pages or webparts ?

The error is "Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION)) ", which correlates to the known issues with publishing page layouts not being available. We originally stumbled upon that after doing a migration of a site from one web app to another using the same content DB. We used Gary Lapoints STSADM extension (http://stsadm.blogspot.com/2007/08/fix-publishing-pages-page-layout-url.html) to help correct it in that case. The odd thing was that when we tested, everything worked fine - when we ran it on the production, it reset EVERY page on the site to use a single page layout regardless of what they were using prior to running the tool. The reason that I mention this one as a symptom is that it occurs on a freshly created, stock out-of-the-box site collection. Below are the event logs received when I performed the operation on the fresh site collection. Medium Unknown SPRequest error occurred. More information: 0x80020009Medium GetFileFromUrl: SPException when attempting get file Url http://<SITE with Correct URL>/_catalogs/masterpage/defaultlayout.aspx Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION)) at Microsoft.SharePoint.Library.SPRequest.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder) at Microsoft.SharePoint.SPWeb.GetMetadataForUrl(String relUrl, Int32 mondoProcHint, Guid& listId, Int32& itemId, Int32& typeOfObject, Object& fileOrFolder) at Microsoft.SharePoint.SPWeb.GetFileOrFolderObject(String strUrl) at Microsoft.SharePoint.Publishing.CommonUtilities.GetFileFromUrl(String url, SPWeb web)Medium Setting [Display] as the FormContext.FormMode for the current pageMedium Setting [Display] as the FormContext.FormMode for the current pageMedium Setting [Display] as the FormContext.FormMode for the current pageMedium Setting [Display] as the FormContext.FormMode for the current pageMedium Setting [Display] as the FormContext.FormMode for the current pageMedium Console: Current page whose properties are being edited: http://<SITE with Correct URL>/Pages/Default.aspxUnexpectedCurrent List Item is null for a published page with rawUrl /_layouts/PageSettings.aspx?Source=%2FPages%2FDefault%2Easpx&CancelSource=%2FPages%2FDefault%2Easpx&Page=1UnexpectedSPContext.Current.ListItem is null for a published page with rawUrl /_layouts/PageSettings.aspx?Source=%2FPages%2FDefault%2Easpx&CancelSource=%2FPages%2FDefault%2Easpx&Page=1Medium PageSettingsPage.LoadValues: a exception is thrown when calling PublishingPage.IsTemplatedPage, exception = {0}

This error sounds like a nightmare !! I read about the fix for this which are like - Restart server / Recreate List/site :)http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/5c8eac8f-0f16-447b-bba4-e3f9b2600947 This is a dicussion similar to the error that you are getting -http://www.eggheadcafe.com/software/aspnet/31533309/error-when-selecting-page.aspxhttp://www.databaseforum.info/10/1113451.aspx

Thanks for the reply maparash_ad.Ya, the whole situation has been a nightmare.But the question still remains, does it sound like a configuration database issue? As an update, I'm in the process of creating a new testing environment with a fresh farm install. Once it's up, I'm going to bring over the databases and recreate the webapps to see if it still occurs. It's about the only way that I can think to pinpoint it and/or find a fix.

Sounds like "the" plan !!

For No .1 are these the steps that you are following - Depending on your situation, applying changes to all of the sites on your server may or may not be a bad thing. If all of the sites on your server need the exact same branding, layout, and functionality, then go ahead and make the change directly in the standard layout folder (after backing it up). But you may just as well find yourself in a situation where each site needs to be different, so applying a sweeping change to all the sites wont work. What do you do when you find yourself in that situation? You make a copy of the shared layouts folder specifically for your site, and make the changes in that site-specific copy. To do this, take the following actions 1.) Navigate to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extension\12\template\ folder 2.) Select the layouts folder and copy it 3.) Navigate to the root directory of your SharePoint site 4.) Paste a copy of the layouts folder in your SharePoint directory 5.) Rename the layouts folder _layouts 6.) Open the IIS manager snap-in 7.) Expand your SharePoint sites website entry 8.) Right click on the _layouts virtual directory (you may also see a non-virtual _layouts folder) and select Properties from the context menu 9.) On the virtual directory tab, click the Browse button next to the Local Path textbox to display the directory selection dialog 10.) Navigate to the _layouts folder you just created in your SharePoint site, select it, then click OK 11.) Click OK to apply the change to the _layouts virtual directory Now you can make changes in the _layouts folder for your SharePoint site without it affecting other sites on your server. Warning: some operations in SharePoint Central Administrator, like extending a site or changing the authentication type for a zone, can reset the _layouts virtual directory in your SharePoint sites so they point back to C:\Program Files\Common Files\Microsoft Shared\Web Server Extension\12\template\layouts. When this occurs, just go back into the IIS manager snap-in and point the virtual directory back over at the _layouts folder copy for your site.REference - http://www.simple-talk.com/dotnet/.net-tools/customizing-the-login-page-in-sharepoint-2007/ Cheers

woo !! I had read about No 1 but to be frank with you, never implemented it as I was not very confident.. I ll give it a try and will update on that..For No 2 .let me see if I can find some documentation !!Cheers

Bill,It is best practice to avoid making any changes directly to IIS and instead do your configuration via SharePoint Central Admin (or STSADM) specifically because of the behavior you are experiencing in (1). Instead of copying the 12 hive, and pointing IIS at your new directory, best practice is to use WSP (WSS SharePoint Solution) files to deploy solutions and features. Don't make any changes to SharePoint files, instead copy them, modify them, and package them in in a WSP using Visual Studio extensions such as WSP Builder, STSDEV, or VSeWSS. This will deploy the files into the 12 hive for you the proper way without overwriting the files created by a fresh install. This is important since if you get in the practice of modifying SharePoint system files, they might get overwritten by a service pack or hotfix. Also, you can make it more difficult to add machines to a farm and upgrade to future versions of SharePoint. For what you are trying to do, you should be able to make the appropriate web.config changes and point to your own login file without overwriting SharePoint system files.Another advantage to using WSP's versus hacking IIS is that if you want to scale, adding another WFE to the farm will not require any customization to IIS, instead a default SharePoint installation will support the automatic download of all WSP's from the Config Database and will update your 12 hive automatically without ever touching the file system or IIS on your new WFE.Talbott

Thanks, I was getting the exact error you were for (2), the Blog Extensions were the cause... even though there is no solution file installed, the web.config is modified for new web applications. removing the httpHandler did the trick... you saved my ring...