Dear All, Whenever we create a new site on the server holding the central administration web app in a MOSS Farm enviroment, it is automatically replicated in the web front-ends servers. What about the site customization like dlls, users controls , features etc? Do i need to copy them over and place them in virtual directories of the relevant web app on the web front-ends as well? Please let me know if someone knows the solution? Thanks in Advance, Sami

SharePoint does not function like most sites hosted in IIS, which is probably why what you're seeing may be confusing to you. When you install SharePoint and set up a farm, the sites created in IIS that are SharePoint sites are going to be configured differently than a standard ASP.NET or HTML application. With a standard app, all of the files used to serve that site to your users reside within the directory for the site in the file system created within the WWWROOT directory (in the INETPUB directory). When you create a SharePoint web application through the Central Admin site or STSADM, a site is automatically created within those same directories, but IIS is configured to point to a folder in the SharePoint 12 Hive (usually C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12), which contains the template files used to serve a SharePoint site. When you create a site collection in the Central Admin site, it is logically placed within a web application, and then hosted on your WFEs through the IIS site associated with that web application. But the template files are not the only piece of the puzzle SharePoint uses to serve up a new site collection. When the site collection is created, SharePoint creates entries for it in the SharePoint configuration database, as well as in a SharePoint content database. When the site is loaded, the data in these databases along with the template files on the WFE are used to compose the site that the user sees in his or her browser. The template files act as the basis for all sites hosted on the WFEs, they are the same on each server and should only be modified in specific ways based on SharePoint development best practices. In an out-of-the-box SharePoint deployment the data in the content database is what drives the unique content and UI that differentiates one site collection from another. When you modify a site's UI with SharePoint Designer, those changes are stored in the site's entry in its content database, not in the template files in the WFEs, which is what keeps those changes from being applied to all sites hosted on the servers. Creating new site collections will not directly impact the amount of storage used on your WFEs to host the site collections, but it does take up more space within your SQL Server instance hosting the content databases. Does that make sense? JohnMCTS: WSS v3, MOSS 2007, and SCOM 2007 Now Available on Amazon - The SharePoint 2007 Disaster Recovery Guide.

Dear John, Thanks for the cool info about the MOSS sites in the Farm. But my site on the app server (i.e. the sever holding the CA) has a lot of custom dlls placed in the bin directory and is using some feautes as well. I place those dlls manullay in the bin since I have taken the backup from another server (dev-server). When I created this web app on the app server it was automatically created on the two web front-ends as well but the bin directory of the application on the front end server was empty..and hence I was unable to authenicate users against the DB. It means I will have to manullay copy those dlls in the bin on front-end web servers as well? Sami

Yes, in that case you will have to manually copy those DLLs over to the WFEs in order for them to be used. If you deploy custom code to SharePoint via WSP files (SharePoint Solution Packages), those are propagated from the server you deploy them on to the other servers in the farm via a timer job. If you manually deploy code to a server's file system (which is usually not a SharePoint development best practice, the recommended approach is to use WSP files), you're going to have to manually copy it to every server that needs the code. JohnMCTS: WSS v3, MOSS 2007, and SCOM 2007 Now Available on Amazon - The SharePoint 2007 Disaster Recovery Guide.

Thanks John! You made my concept clear about this.