I am setting up a new SharePoint 2013 Enterprise environment.  It will be a relatively small farm with a single server acting as Web Server and App Server and a SQL 2012 DB server for the backend.  We have around 100 users.

I was attempting to configure My Sites and I noticed the TechNet article suggests that My Sites have their own Web Application.  But when I was researching this last month I read a different TechNet article that said the preferred architecture is to have a single Web Application and use Host Named Site Collections.

I foresee us needing these Site Collections:

• Sites for each department
• Search Center 
• My Sites
• Document Center
• BI Center

I know I can accomplish this using a single web application and path based collections, a single web application and host based headers, or multiple web applications and host headers, but I'm looking for the pros and cons of each method.

Users are accessing the site via RDSH servers and we are using NTML security.  There won't be a need for a lot self site creation, in fact once it's setup I don't see a lot of site collections or pages being created.  Basically I just want the URLs to be user friendly and site navigation to be as simple as possible.

Can anybody help clarify the differences for me?

The preferred Best Practice in SharePoint 2013 is now to minimize the number of Web Applications and particularly the number of Web Applications with Host Headers.  this is primarily due to the introduction of Apps in 2013 and the performance data Microsoft has gathered from their experience running office 365.  So here is the pattern most of my clients use:

• 1 Web app on a custom port for MySites
• 1 Web app on port 80/443 for everything else.
• Sites that need custom addresses are implemented as host named site collections on the everything else web app.

MySites is a special case.  you can create it on the main web app and have everything on one.  But that complicates capacity planning for content databases unless you create a custom site provisioning system.  So I like to still keep them separate.  But you should definitely minimize the number of web apps and stick to differentiating between them based on IP address or port number instead of using host headers.

The preferred Best Practice in SharePoint 2013 is now to minimize the number of Web Applications and particularly the number of Web Applications with Host Headers.  this is primarily due to the introduction of Apps in 2013 and the performance data Microsoft has gathered from their experience running office 365.  So here is the pattern most of my clients use:

• 1 Web app on a custom port for MySites
• 1 Web app on port 80/443 for everything else.
• Sites that need custom addresses are implemented as host named site collections on the everything else web app.

MySites is a special case.  you can create it on the main web app and have everything on one.  But that complicates capacity planning for content databases unless you create a custom site provisioning system.  So I like to still keep them separate.  But you should definitely minimize the number of web apps and stick to differentiating between them based on IP address or port number instead of using host he

New sites would be created using host headers eg.

hr.sharepoint.contoso.com

intranet.sharepoint.contoso.com

I think that it might be impossible to mix and match so all site collections would be using host names and none using managed paths. Even if it's not a technical limitation i'd do that for consistency if at all possible.

Your MySites should be all be under a single web application such as:

mysites.contoso.com

(eg: http://mysites.consoso.com/personal/AlexB,  http://mysites.consoso.com/personal/DaveS )

I don't believe that the my site provisioning process can handle host headers so it'd just work on the old approach.

Your MySites should be all be under a single web application such as:

mysites.contoso.com

(eg: http://mysites.consoso.com/personal/AlexB,  http://mysites.consoso.com/personal/DaveS )

I don't believe that the my site provisioning process can handle host headers so it'd just work on the old approach.

Exactly, although if you're creating it afresh then i would drop the silly port number. The only reason that's in place is to allow you to use the same URL for multiple web apps.

What i often see is "http://mysite.contoso.com" for the main URL of the web app, then an additional "http://mysite" url added in DNS and Extended as an AAM as a friendly url for users, although some security teams dislike this.

This is exactly what I've been struggling with the past few hours (well, weeks, ok months) for our migration to 2013. So I guess there's really not a best answer then? I was going to post the same exact question. I'm not sure which direction to go, and we're going to go live with the migration. I've tested it both ways so I'm confident we can do it either way, just not sure which route is best.

I have 2500 regular users (though most of those don't use our intranet every day). I pre-built 4600 mysites (we're only migrating 61 sites since only  61 people have anything besides a profile pic in their mysite).

I created all 4600 using a hostnamed site collection as the mysite host header in the main webapp (using a farm-wide /personal wildcard managed path with the -hostheader switch on Set-SPManagePath).

It works well, though it's been a pain to manage. And I just read the same article linked above, and thought to myself "seriously?" Luckily since we're not in production yet I have time to play.

I found out to switch over from using a hostnamed site collection as the mysite host to a separate hostheader webapp and "/" as the mysitehost I need to do a Backup-SPSite and Restore-SPSite on every mysite as well as the host site. Luckily since they're all empty, backing up 4600 mysites has only taken an hour.

The only problem, and what tempted me to set them all up in the same webapp in the first place, is that internal users get prompted to log in when switching webapps. I'm using Claims NTLM, and both webapps are using the same apppool.

There's a few things that jump out in that Chris.

For a start the move to 'one Web App to rule them all' is debatable, it's really important for big organisations or hosted organisations but for most of us it's guidance rather than a 'must'.

Personally unless you've got a perfect user creation process i wouldn't use host named MySites, there's too much risk for one to be missed and then it all gets confusing. Also it requires pre-creation of MySites which is wasteful of SQL storage.

The prompting is normally caused by the site not being present in the trusted or intranet zones. If it's there it'll generally just have the credentials passed to it without the user being prompted.

This is exactly what I've been struggling with the past few hours (well, weeks, ok months) for our migration to 2013. So I guess there's really not a best answer then? I was going to post the same exact question. I'm not sure which direction to go, and we're going to go live with the migration. I've tested it both ways so I'm confident we can do it either way, just not sure which route is best.

I have 2500 regular users (though most of those don't use our intranet every day). I pre-built 4600 mysites (we're only migrating 61 sites since only  61 people have anything besides a profile pic in their mysite).

I created all 4600 using a hostnamed site collection as the mysite host header in the main webapp (using a farm-wide /personal wildcard managed path with the -hostheader switch on Set-SPManagePath).

It works well, though it's been a pain to manage. And I just read the same article linked above, and thought to myself "seriously?" Luckily since we're not in production yet I have time to play.

I found out to switch over from using a hostnamed site collection as the mysite host to a separate hostheader webapp and "/" as the mysitehost I need to do a Backup-SPSite and Restore-SPSite on every mysite as well as the host site. Luckily since they're all empty, backing up 4600 mysites has only taken an hour.

The only problem, and what tempted me to set them all up in the same webapp in the first place, is that internal users get prompted to log in when switching webapps. I'm using Claims NTLM, and both webapps are using the same apppool.

• Edited by Christopher Buchholz Thursday, July 25, 2013 11:13 PM xxxx

This is exactly what I've been struggling with the past few hours (well, weeks, ok months) for our migration to 2013. So I guess there's really not a best answer then? I was going to post the same exact question. I'm not sure which direction to go, and we're going to go live with the migration. I've tested it both ways so I'm confident we can do it either way, just not sure which route is best.

I have 2500 regular users (though most of those don't use our intranet every day). I pre-built 4600 mysites (we're only migrating 61 sites since only  61 people have anything besides a profile pic in their mysite).

I created all 4600 using a hostnamed site collection as the mysite host header in the main webapp (using a farm-wide /personal wildcard managed path with the -hostheader switch on Set-SPManagePath).

It works well, though it's been a pain to manage. And I just read the same article linked above, and thought to myself "seriously?" Luckily since we're not in production yet I have time to play.

I found out to switch over from using a hostnamed site collection as the mysite host to a separate hostheader webapp and "/" as the mysitehost I need to do a Backup-SPSite and Restore-SPSite on every mysite as well as the host site. Luckily since they're all empty, backing up 4600 mysites has only taken an hour.

The only problem, and what tempted me to set them all up in the same webapp in the first place, is that internal users get prompted to log in when switching webapps. I'm using Claims NTLM, and both webapps are using the same apppool.

• Edited by Christopher Buchholz Thursday, July 25, 2013 11:13 PM xxxx

Mysites, particularly personal mysites are almost never accessed directly by typing in the URL.  99% of the time you reach a mysite because you clicked on a persons name or a link in the navigation.  So there is no need to make them user friendly.  The one concern with using a custom port number is if you have external users make sure that it will route through your firewall.  Otherwise put the mySites web app on a custom port number and don't use a host header.

No you can't use a host header on the "everything else" web app or you won't be able to use "Apps" since they generate a dynamic URL that won't match the host header.  Besides there is no need to do it to create a friendly url.  Without a host header you can use any base url you want by setting it up in DNS.  Your main Web App should be created with No host header.  You can create host named site collections under that if you want specific urls for specific site collections.

Web Applications on a server need to be unique in one of three ways.

• Custom IP Address - Can't do this in the SharePoint UI.  The Web site needs to be pre-created so its extra work.
• Host Header - Host headers at the Web App level will cause a problem for the new SharePoint Apps. 
• Custom Port Number -

So you can't just use a different URL unless you are implementing host headers and host headers at the Web App level cause issues in SharePoint 2013. 

So NO, don't drop the silly port number.  Its necessary if you aren't using Host Headers.

Web Applications on a server need to be unique in one of three ways.

• Custom IP Address - Can't do this in the SharePoint UI.  The Web site needs to be pre-created so its extra work.
• Host Header - Host headers at the Web App level will cause a problem for the new SharePoint Apps. 
• Custom Port Number -

So you can't just use a different URL unless you are implementing host headers and host headers at the Web App level cause issues in SharePoint 2013. 

So NO, don't drop the silly port number.  Its necessary if you aren't using Host He

My understanding is that Microsoft best practice is to also create a My Site site collection and move it under that single Web application ("1 Web app on port 80/443 for everything else") instead of having a separate web application for My Sites

reference: http://technet.microsoft.com/en-us/library/cc424952.aspx

• Edited by Hossein Aarabi 13 hours 37 minutes ago

My understanding is that Microsoft best practice is to also create a My Site site collection and move it under that single Web application ("1 Web app on port 80/443 for everything else") instead of having a separate web application for My Sites

reference: http://technet.microsoft.com/en-us/library/cc424952.aspx

• Edited by Hossein Aarabi Friday, October 04, 2013 9:26 PM

Replying late but wanted to add that it is possible to add host headers to web application even if you are creating HNSC underneath it. Even though the below article talks about 2010 it is possible to do the same thing in 2013.

http://blogs.msdn.com/b/markarend/archive/2012/05/30/host-named-site-collections-hnsc-for-sharepoint-2010-architects.aspx

But I wanted to add one thing that I have not tested Apps problem that Paul Stork states.

Hope this helps someone

Paul,

If I understood this conversation, this is how I provisioned SP2013.

One Web App at: http://<serverName> on port 80, no Host-Header

One Web App at http://mysite.contoso.com:8080, no Host-Header

So then I then provisioned via PowerShell a HNSC on http://<serverName> with its own Content database and then on the MySite web App which has its own Content Database, allowed Self-Service site collections for the users MySites.

So going forward, I've written a PowerShell script to provision new Site Collections with their own Content Databases as a Host-Named Site Collection on http://<serverName>

This sounds like the ideal scenerio that you describe. See below. Am I correct?

The point of having My Sites on its own Web App is that you can let the provisioning engine stripe them across multiple content databases without mixing them in with regular site collections.  For collaborative site collections the creation process is less self service and more deliberate normally, so you don't normally need a special web app for them.  Since its more deliberate you can use Powershell when creating collaborativesite collections to choose what content database to store them in.

One Note: Each Site Collection will be associated with no more than one Content Database.  A content database can contain multiple site collections, but each site collection can only be in one content database.