think of site collections as individual containers. Each one is separate on to itself. The content in each site collection is separate from other site collections. Templates and site definitions can be used to create a default workspace with defined lists and libraries along with workflows and features that are activated.

site collections are designed to store like and similar content. If each site collection is storing the same content then maybe site collections are not the way to go.

I am not sure what the 80% of content is, but if it is content that should be unique or requires audits and such, then having multiple locations ofr the same content would (or should) fail the audit.

Not knowing your content, you can possibly use content deployment functions as part of MOSS using central administration (or WSS you have to use the STSADM command line utility) to push the content to all the site collections.

Angie,

There are a few ways you can do this, but not sure if any of the ways are what you are thinking...

#1: Content Deployment

Deploy content to multiple sites. This requires paths and jobs setup though central administration or manually using the command line STSADM utility. Still duplicates will then exist on every site.

#2: Page Viewer Web Part

Create a site that contains the common content then have pages created with page viewer web parts that render the content from the common site. This way there is only a single source for editing / maintaining.

#3: Site Definition or Features

Create a site definition template or a feature that contains the content as ghosted. This way the content exisits on the file system with the site def or feature and sites can then use that content. This still gives the single source benefit, plus allows for each site to customize if needed.

hopefully this helps.

Nope, site collections are not able to see other lists in other site collections. You would have to develop a custom field type to accomplish this.

No. Part of the hierarchy of site collections are that an entire site collection is contained in a single content database. You can have multiple site collections in a single content database but you cannot have multiple content databases for a single site collection.

I do know that SharePoint will choke if you try to create a site or already have a site created where a managed path will be used. I have ran into that in the past and it was a pain to get it resolved (at least in 2003 it was).

I haven't tested this out, but what I was thinking you would have to use is explicit managed paths. You would need one for a/b/c and a/b. I am leaning towards this not working. I honestly don't think you can have site collections that conflict with managed paths.

well, this depends on the deployment of the master pages, layouts, content types and web parts.

by default sharepoint shares these items within a site collection, so the quick answer would be to keep it all in a single site collection.

but if you are deploying these items as a feature / solution package then you can deploy them to multiple site collections keeping the solution project as the source file for these items. There is more work involved in the deployment method, but you might benefit in the future using a deployment scheme allowing you to use the mutlitple site collections.

you will have to wiegh the benefits of site collections vs sub site plus the pros and cons of creating a deployment package.

I get this question alot, and usually it comes down to what i most important to what the customer is doing with their environment. You need to balance the flexability and features of a site collection with its limitations.

The limitations of a site collection are there for a reason and that reason is because site collections are not suppose to be related to anything other than itself. Site collections are a means to provide a stand alone secure container to allow like content to be shared within. This means that site collections and their duties can range from a corporate portal down to a simple project adhoc workspace.

Also where customers get confused in the concept is that they expect all naviagion and flow of the portal down to those projects sites to be seemless. Although Microsoft does give you the ability to attempt this with managed paths, and "connect to portal", the reality is that it doesn't encapsulate everything.

Using CQWP across site collection is not possible, you need to write a custom query part to do that.

Master pages, page layouts, content types, site columsn, etc.. would have to be packaged and shared through a solution and features.

Themes are at a farm level and are automatically avaliable for all sites in a farm.

Backups in 2007 can be done from a farm level down to a database level, plus with STSADM you can backup site collections. There is no full backup for a site level.

In 2003, you had "smigrate" which was the frontpage backup site method. That is gone in 2007 and replaced with content deployment mechanisums "export and import". These operations can be found under STSADM or under central administration content deployment section (only for MOSS).

Record center is just a site template, you can apply that just like any other template at any level in any site collection as many as you need.

Also, to elaborate on the CQWP Across site collections, you can do alot with enterprise search mapped properties to site columns. Dan Attis wrote a greate article as an example:

devcow.com/.../SharePoint_2007_How_to_Rollup_Content_from_multiple_Site_Collections.aspx

Everything in the site collection will be contained with a backup of a site collection. Make sure that the images and templates you downloaded exist on the farm and web application that you restored the site collection to. The content in the site template gallery should come over with the backup, any images that are located outside the site collection refereneced relativly might not have the same relative path in the new location. There is not enough information in your comment that I can offer a direct answer to. Hopefully this helps.

Use Search... :)

Think of the intranet as how a user uses the internet. On the internet there is no way to keep up with the information that is available by using manual links. Yes there are more important pieces of information that will require a link to make it more easily available. That content is usually not moving around alot and has a set place where it needs to be located, but for more targetted information for an individual, search is mostly used.

On your intranet, it would be virtual impossible to keep up with manual links that are important to all individuals. If an individual uses the search functionality of sharepoint they would be able to find more targetted information that pertains to them and the information they are looking for.

This of course all depends on the search being configured properly for the information people are searching on regularly.

Hope this helps.

For the most part depending on what needs to be shown and if there are no security issues, you could create audiences for each country.

As for the variations, yes they can be contained in the same site colleciton. and in conjunction with the audiences, you can use variations for the languages.

for the most part it might be easier to have each country be their own site collection to keep the management of the content using audiences down. It will depend on if you want to have duplicate content in multiple site collections or manage a single copy of the content allowing only specific content by using audiences.

Yes, you are correct that you can apply unique security at the stie level, but keep in mind that sharepoint groups span the site collection level. this means that IT groups then are managed in the same area as HR groups or any other sharepoint groups. Also site collection administrators are not useful in this scenario since you cannot give IT user or HR user site collection admin status as they will automatically have admin permissions everywhere. There is also the "all user information" area. all users who visit the site are automatically entered into the all users information area, this can get quite full and confusing for managing users at any level throughout the collection.

The point i was making is that since site collections are unique onto themselves and do not interact with other site collections, you can assign owners to the sites. These owners can then manage their own security groups and members without affecting or being affected by other departments, teams, or projects.

The recycle bin has 2 stages. The first stage is based on a time limit (default 30 days). The second stage is based on the a percentage of your site quota (default is 50%). Plus the first stage is counted against your site quota limit, where the second stage is not. The second stage bin runs a first in / first out process.

So HR deletes a very important 100k fle on day 1.  IT deletes 1GB of content over the next week. Your site quota is 2GB, which means that your second stage recycle bin is 1GB by default. In 30 days this content gets moved out of the time based bin into the second stage bin which has a quota of 1GB. Since IT has deleted 1GB of content that week, the HR 100K file will be flushed out of the system on day 31 or so.

Now if HR had their own site collection and recycle bin storage. That 100K file could be around for a year compared to just over a month.

What you are describing is the ability to link the site up to the "Portal", which is whatever you decide to enter in as a URL. This connection will show up in the global breadcrumbs in the upper left of the screen. It will provide a link back up to the corporate intranet.

If the top or left navigation expectations are that they are the same no matter what site collection you are on there is two ways to do this.

1.) manually maintain the navigation (which removes the posibiliy of security trimming)

2.) Custom develop a site map provider that builds the appropiate navigation heirarchy based on site collections.

Dave, there is nothing out of the box that will give you a list/report of the site collection administrators for every site collection. You will have to write a custom piece to extract that information.

You could possibly use the content databases and write a SQL query to pull the information out, but I do not recommend it since it is not supported by Microsoft.

Brian, Web Applications are designed to handle multiple site collections. You can think of a web application as the equivelant to a IIS Virtual Server. The web application is technically just a container when created. It does absolutly nothing until you create a site collection.

When you create a site collection, you need to specify which web application the site collection will be contained. By default there are 2 managed paths. One is a root level (/) and the other is called "sites".

The root level managed path represents an explicit path which means that only one site collection can be created at that location. The "sites" managed path is a wildcard path, which means that multiple site collections can be created using that path.

Multiple web applications can use port 80, but they have to either be on a different IP address, or use a host header. Site collections run under the context of a web application, so one web application running under port 80 means that many site collections can run under the same port..

If they want a custom URL, you might need to consider creating a new web application for them, or look into using site collections with host header mode. Host header mode allows you to specify a DNS name for a site collection. I am not sure of the exact details, but you can see the option under the stsadm -help createsite command.

I don't think you are going to get the content types and site columns to come over with the export/import commands. The recommended method is to create a feature that contains all the shared content types and their related site columns. That way you can deploy to any site or site collection in your organization. There is a tool on codeplex that allows you to export content types to build the feature for cross farm deploymnet (www.codeplex.com/MOSS2K7CTypesViewer).

tmmurphy,

There are two types of managed paths, wildcard and explicit. By default a web application has a "/" explicit managed path and a "sites" wildcard managed path.

The explicit managed path allows only a single site collection to exist at that path. So anything underneath that path will be sub sites of that site collection. (Example: http://www.domain.com/)

The wildcard managed path allows multiple site collections to utilized that managed path. So for example the default "sites" wildcard managed path will allow multiple site collections to utilize it as shown below...

http://www.domain.com/sites/sitecollection1
http://www.domain.com/sites/sitecollection2
http://www.domain.com/sites/sitecollection3

If we break it down...

http://www.domain.com = Web application
/sites = wildcard managed path
/sitecollection# = top level site (site collection)

if we break down the explicit managed path...

http://www.domain.com = Web application
/ = explicit managed path & top level site (site collection)

So basically you can use either sharepoint designer or the stsadm export/import commands to take a sub web (ex: http://www.domain.com/subsite/demo) and turn it into a site collection using a wildcard managed path (ex: http://www.domain.com/sites/demo). You can create custom managed paths for say departments or projects. (ex: http://www.domain.com/departments/hr) that way they look like they all fall under the "/" root level of the web application in a more defined heirarchy other than just using "sites".

You can try to use the stsadm o renamesite operation, but based on Microsofts KB article (support.microsoft.com/.../939535) it doesn't work with path based site collections.

If the stsadm command does not work for you, which based on the information it probably won't, you will have to do a backup / restore of the site collection into the new managed path. Obviously make sure the new manage path exists before attempting to restore.

stsadm -o backup -url http://hostname/helloworld -filename hw.bak

stsadm -o restore -url http://hostname/hw -filename hw.bak

Alan,

With MOSS you gain the ability to search across site collections. WSS you can only search within the site collection.

MOSS will provide you the ability to search across the entire farm, plus additional areas such as exchange public folders and file shares. The search results are security trimmed so if the current user has permissions to see a certain area, they will see results from those areas.

www.sharepointblogs.com/.../original.aspx

It was on another service, i moved it over so you should be able to see it now.

Determining on when to use web applications is usually related to authentication types. You can have multiple authentication types in MOSS, but only 1 per web application. Another decision point is the content and how you are required to organize it and secure it.

From what you said you have an intranet and a extranet. Does the extranet require different authentication? if yes, then it has to be a new web application. Does the intranet contain content that is sensitive that should not be exposed outside the company? if so, then the extranet has to be a new web application.

Another thing you can do is if your intranet can be exposed to the outside, but still requires different authentication, then you can create a new web application that extends your intranet. What this does is allows two web applications to access the same content each with their own authentication.

I wouldn't use a site collection for this because you still have to expose the entire web application to the outside to get to the site collection. You are better off thinking in terms of web applications for the intranet and extranet. Plus, the extranet won't be a single site it is a network of sites, so your extranet web application most likely could contain multiple site collections itself.

The problem is in the "pushing" of documents (and maybe content). You shouldn't have to push documents to the business units (such as forms and such) The employees should come to it. Each business unit could provide an informative page that allows their users links to get the information from corporate.

Think of corporate as just another business unit. If someone in BU-1 wants more information about what BU-2 is doing, they would go to the BU-2 site. They shouldn't expect to find that information on their site since it doesn't relate to BU-1. Point is.... Keep the content at it's home and have people come to it to consume it rather than having multiple pieces of the same information floating around out there.

For sharing announcements or aggregating content across site collections, I recommend using search. If you are running MOSS, then you can create your announcements in a structured manner (such as content types and site columns), then configure search managed properties to map to those columns, then you will be able to use the search core results web part (Again, MOSS only) to retrive that spceific content and render it with a custom XSL layout. With this option the content is still "at it's home" just being rendered in another location.

Sure, you can have search pull the specific information, the underlying calendar content are just list items, which can be structured with content types and site columns to assist search in returning those results.

The issue comes with rendering the information. You would have to do some amazing XSL work to get the information displayed in a calendar view.. :)

I think that is a political issue. If corporate controls these items outside of the business units I don't believe this should be any different in SharePoint or any intranet.

The only way I can see each business unit being able to maintain their own corporate level sites, is the information for each business unit is unique and cannot be used by any other business unit anyway.

If you need to do this I would see how the "search" option works for whay you need to do. This will provide the consumption of the content from the BU site, but still host it in the proper location. Keep in mind duplicating data should not be an option. thats just poor business practice.

Cat_SJ,

Based on best practices and recommendations I would recommend against creating a database for sharepoint outside your sharepoint environment. Also, you will have to make sure all the permissions are in place for SharePoint to create and continue to manage the content database.

with that said, there is nothing in the technology that will keep you from doing so. First you must create the content database before creating the site collection. The database can be created by going to central administration -> application management and clicking on "Manage content databases". Make sure to select the web application you want to host the database and click on the "Add Database" link in the toolbar. From there you have the option of specifiying the sql server to host the new database.

Once the database is created, you can create the site collection. First you have to make sure the databases are configured properly so the new site collection goes into the correct database. Under the same "Manage content databases" section, you have to specify the number of sites allowed per database. You do this by clicking on the database name and setting the site warning and limit settings.

What I usually do is set the limit to the number of current sites + 1. (you have to add one because the system won't take it if the limit and the current number match). then make the warning smaller then the limit. This is done on the database you do not want the site to go into. On the database that you want the site to go into you have to make sure there is room in the database based on the site limits specified. by default it specifies 15000 so there should be plenty of room.

When this is done you can create your site collection and it should go into the database that has room for it. Once the site collection is created in the new database and if that is the only site collection going into that database, then set the limits of the new database, based on the information above, so no new site collections can be added to it.

Communications between site collections are primative. There are a few ways to do this.

Quick and easy route: Use Links

You can use a links list to provide access to different areas of your environment

Moderate route: RSS

You can utilize the RSS options for lists and libraries to share information across site collection boundaries

Advanced route (MOSS Option only): Search

You can utilize custom search web part as a rollup list. This requires the creation of custom search managed properties which tie to metadata in sharepoint lists. The search results web part can be configured to target these managed properties to return precisly what is required. Also search results are security trimmed, which is sometimes a requirement for inter-site collection communication.

V2,

These are all good ideas for posts.. thank you. unfortunately I haven't done anything around these topics, at least publically. I do have some information related to these (especially setup and installation) and will be posting them shortly.

Samer,

Microsofts answer to aggregation is Content Query Web Part (for intra site collection content) and their only real good solution for inter-site collection aggregation is search. If you are running MOSS, you can configure search to return the information you are looking for.

With the use of content types and site columns in conjunction search managed properties will allow you to configure the search core results web part to pull only specific relevant information. The bonus is since it is useing search to return this information, it is automatically security trimmed as well.

Since search results are returned using XML, all you need is to configure the XSL to render the content any which way you need. Making it into a calendar might prove complicated with straight XSL, but I am sure it can be rendered in such a way to make it a quick win for your situation.

Other options of course rely on developing a solution using .net, especially if you choose to render into a calendar.

Tasneem,

My recommendation is to not include the private collaboration information within the public site collection.

What I usually recommend is a public intranet site collection, which has public departmental information as sub sites. Then the private information is contained in their own site collections.

example...

http://intranet.company.com/

this is the root level site collection in the web application which contains the companies intranet which is public "formal" tightly governed information.

http://intranet.company.com/projects/???

site collections can use managed paths to define and organize team sites. Such as a projects managed path where all the project based site collections can be created, or a /departments/ managed path which allows department team sites to be created, or /sites/ which can be used for virtual team sites in general.

Keeping the private sites organized by specific topics which allow for better administration, maintenance, and lifecycle management of the site. along with providing the owner a more loosely goveren workspace for them to build something which suits their needs vs. someone elses.

Rita,

Yes, feel free to use my image in your documentation.

That is correct. You cannot specify 2 managed paths with the same name. Also you will want to stay away from having a wildcard managed path named the same as a sub-web under the root level site collection. This will cause sharepoint to get confused.

Take a look at using host header mode. You can esentially create "vanity" urls for each customer site collection. for example... http://customer.domain.com/ and creating sub webs for each project (http://customer.domain.com/projectA).

Keep in mind, having all projects for a customer as a sub-web is ok as long as 1) you don't need specific lifecycle management for each project 2) user permissions are the same (you want to stay away from too much unique permission management) 3) archive ability using backup methods or locking mechanisums provided by SharePoint. You might run into management issues in the long run by having projects as sub-webs under a customer.

Although sub-webs provide a better means for sharing content types, site columns, and rollup capabilities... I would make sure you weigh all the pros / cons on creating them in site collections vs. sub webs.

Kevin,

Let me break down your response and clarify each section...

Lifecycle management?

quick answer... yes. You want to position yourself and your environment to be effective in the long term as well as the short term. This means you have to develop a plan for archiving sites, being able to move sites between databases, content databases utlization, disk utilization, site locking, site disposition, etc.

Keep in mind how Microsoft has designed SharePoint. A content database can contain multiple site collections, although a site collection CANNOT span multiple databases. This is a main point of concern. Putting projects as sub-sites in a single site collection for a custom means you can only have one database. Multiple projects and the data associated with these projects can grow out of control if not propertly planned out. Also you cannot offer storage quotas for sub-sites... they all use the site collection storage quota. This means you either not set one (bad idea) or set one and have any one of the projects potentially utilize all the space for themselves.

Permissions?

What I mean by the same permissions is you don't want to get into the habit of managing unique permissions for sub-sites on different projects because it can get messy. If all the projects have the same permissions then great inherit permissions from the parent and manage the permissions in a single location. I tend to think this is not the case at the customer level. Odds are the permissiosn are unique at the project level.

With this said, you need to develop a plan for user management. This goes back to thinking for the long term as well as the short term. Short term you throw a sub-site out there, manage permissions for a few people who may just need access to that project... then before you know it they have you managing permissions for all projects across all customers. You need to delegate this out to project managers / admins. can you do this in sub-sites... sure, but now there are multiple different admins intertwined into the site collection structure, which means more uncontrolled growth. With a site collection you can more easily manage this piece as well.

Ah the infamous question, how do I manage all my projects for a customer in one place?

The easy answer... use a site directory. If you have moss you can utilize the site directory template for each customer which can provide a list of projects for them on their site. If you don't have MOSS and have WSS, you don't have the site directory template. Since the site directory template uses lists to store its data, you can create a custom list for them to track their sites with a list.

Another direction... use search. Again, if you have MOSS you can easily incorporate search to provide a list of site collections. The best part, search is security trimmed... meaning customers will only see site collections in which they have access to in the list. Since search results are rendered with XSL, you can easily customize the output the customers see.

Bottom line...

I highly recommend taking at least a couple days to make sure you cover most your bases and develop a long term strategy for sustaining the environment. Yes I know you won't be able to think of everything, but if you look to the past in how the company has done business and their trends and then follow within the lines of how Microsoft has architected SharePoint to work, then odds are for you in the event an unknown comes up. A well thoughout plan makes life easier for you in the long term. If there is no plan, every issue is a fire drill and a band-aid fix, which lead to more intense fire drills. You want to reduce the occurances and intesity of the fire drills and effectively resolve any unforseen issues... the best way to do this is to have a plan of attack and stay one step ahead of the curve.

Frank,

It is not a rule to keep private and public information separate. The separation allows you to govern the content differently. If you have people continuously working on private content in a public environment, this means the administration of this could become more cumbersome. Usually public content is goverened and secured to where there are only a few allowed content authors where as a private area would allow for more contributing parties to secure without affecting the security structure of the public information.

You could keep all the contracts in a private area to work on them and expose just the contract information in your private area for colleagues to consume. If the contracts are designed properly (content types, specific site columns) and are provisioned and mapped to search specific properties. You can utlize the search web parts to essentially roll up this information on your public site for all to consume. (example fixed keyword search syntax: contenttype:Contract)

As for the other question. There is no hard limit on the size of a site collection and it will continue to grow as long as your database hardware allows. With this said you increase risk into your site collection by doing so. I have seen companies put everything in a single site collection ranging to 100GB+ while trying to secure each level of a site collection just to be able to use something like the CQWP or the "manage site structure" functionality. But you will increase risk to backup / restore recovery times, plus the stsadm commands for backing up just a site collection will be unable to effectively backup and restore something that large. (10GB is usually the limit on this). Then you have to worry about the amount of activity and transactions occuring on a single database in SQL Server and whether your hardware can keep up with the data locks not conflicting. Keep in mind everything in a site collection is stored in a single table in the database. This means every item from and list or library (document is stored in another table, metadata and reference is still stored with all list information) is stored in a single table. If you have all sites in a single site collection all lists items in every site is stored in a single table... I have seen 500,000 items plus in this table before... you have to also make sure your database hardware can keep up with delivering the specific queries from this table, even though it is indexed the more items you contain in table the more it has to index and sort through to find items for a specific list or library to display in your browser.

Sorry for rambling... hopefully this infromation helps you out.

Manish,

With development in SharePoint, you want to see where in your application does the features of SharePoint provide value and build modules to extend what SharePoint already gives you to complete the objective of your application. Meaning you don't want to reinvent the wheel developing an entire application from scratch essentially duplicating functionality of SharePoint, just to surface and integrate with SharePoint. Use SharePoint as a platform and extend where needed.

First I would identify the functionaly required for this application and where this functionality overlaps with SharePoint functionality. If your requirement is to have an individual be able to track training information and be advised of additional training which pertains to them. Evaluate where SharePoint already gives you this functionality... SharePoint already can do audiences targeting specific content, alerts, storing of a list of information, etc... then you are left with the pieces you need to develop to extend SharePoint to fill the void. such as to add an action to a list or item which will auto register the user based on information from their My Site user profile, then track the information back in their my site.

SharePoint provides the ability through it's API and web services plus the Office client application to produce an application which delivers the functionality you expect without having to develop databases, underlying principles for the storing and disposal of content, scalabiltiy, authentication, etc... Through the use of deployment through a sharepoint solution package and activation in the site's which require this functionality through the "Features" feature you should be able to design it in such away to deploy the solution granular enough to meed your business needs.

As far as the A and B listed in your comments... item A is essentially a personal site or what is often refered to as a "My Site". I wouldn't create additional site collection outside of the My Sites. Item B is more along the lines of creating team sites or departmental sites.

Manish,

Well there is no linkage or relationships between site collections in SharePoint. So linking up an individual site to a organization site would not be an option.

Since you mentioned WSS, using my sites and user profiles is not an option with WSS. If you have MOSS you would be able to utilzie My Sites and user profiles to at least provide relationships between people, but still not organizations. There is no organization relationship feature for SharePoint. You would have to custom develop this feature..

As far as A and B go... I would say use both. If you are using MOSS you can utlize My Sites and user profiles to provide the automation of creating personal sites for individuals. If not, you would have to develop a process or automated feature that would provision a site collection per individuals. Organizations deserve their own site collection as well. This will provide an area for each organization to collaborate.

I would not recommend creating an organization site collection then having individual sites per person underneath. This will make for an administration nightmare as people move or come/go from different orgs. Having them in site collections allow you to more easily archive, provision and move if needed.

Karam,

Sounds like you have a lot going on there. As far as web applications are concerned, You can include the portal site collection and the country site collections into the same web applicaton. You may want to think about creating managed paths for each country (http://webapp/country/site) in the event you will have more than one site collection per country.

Application pools allow you to seperate out isolated processes on a per application basis... be careful as you have to scale these based on your server specs. To many can eat up your memory if not configured properly. The recommendation is the web app with central administration is to be in its own application pool with its own identity. Other than that it is up to you and your server specs on how you configure the remaining web apps.

You can manage the local country search with the SSP on the regional farms, but for a global search you would need to index the other farms as well. this is usually done from a "central" farm and people are directed to the central farm to search globally. this is because the farm which provides the global search has to index the other farms which can be an issue because of your network.

Andre,

The seperate project server will contain their own site collections on a per project basis. I don't think I can give you a suffiecent answer based on such a brief description. I would say the 30-50 department sites would each be their own site collection, but after that I am not sure.

Carol,

Are you asking how to manually copy the information over while retaining the workflow, or how to have a workflow copy things from one document to another.

I assume the later. You can develop a workflow which copies information from one site to another. However, it would have to be a visual stuido workflow as SharePoint designer workflow wouldn't be able to cross site collections.

technically you would have 2 content databases if you have 2 web apps. However, that is only if you "create new" web applications. if you "extend" a web application, then you would have 2 web apps (IIS Websites) pointing to the same content database. This allows for multiple authentication types to be configured to access the same data.

If your just talking sharepoint, you cannot have a pure anonymous web application since you have to pick Windows, Forms or WebSSO for the authentication type when creating or extending a web app. However, once it is created or extended, you can configure the corresponding IIS web stie to be just anonymous without integrated authentication configured.

As far as being more secure... it probably is, but at what expense. The additional effort for configuration and maintenance may out weigh the minimal gain of security.