I'd like to create a mysites web application at http://www.domain.com/mysites. This is so that mysites always end up in the only database tied to that web application.
However when you create an additional web application you are required to use the dns to define its location (for example: mysites.domain.com).
Does anyone know how to do this?
The MS documentation on My Sites in SharePoint 2010 is actually pretty good - check out Plan for My Sites (SharePoint Server 2010).
The basic recommendation is to use a dedicated Web application for My Sites, and to use the root path for the My Site host collection. Whilst you could potentially create the My Site host collection deeper in the path, e.g. /mysites, it must be under an explicit inclusion managed path.
My recommendation would be to keep it simple if at all possible, and simply create a new Web application with a separate content DB for My Sites.
I'm sure there is a way to accomplish this, but a better response would be "Why do you want to?"
In SP2010 (and to a lesser extent in SP2007) a MySite is intentionally not tied to a web application because the intended use is that each farm will only have one MySite for a given audience but will have multiple web applications, each of which can and should leverage the same MySite.
Real World example : a company creates a collaboration site in SharePoint 2010 and makes MySites available for people to use. A few months later, they want to leverage SharePoint further and put up a Intranet portal that leverages publishing. Would you really want the same set of users to have a MySite for collaboration and a different MySite for publishing?
In the example above, had you embedded your MySite into your collaboration content DB, you would now be in a position where you would have two completely separate content databases now coupled by the embedded MySite. This gets even worse when a particularly sensitive division in the company, like Legal or HR, wants their own dedicated collaboration site as now they would be tied to that content DB as well.
All that said, you can't use SharePoint 2010 and be worried about the creation of databases as 2010 is a database creatin' fiend. Simply by flipping the switch, you've already created about a dozen or so. If you are really worried about managing SharePoint databases, create a dedicated instance of SQL Server and make that your default database server in SharePoint. That is an emerging best practice anyway because of how hard SharePoint hits the TempDB database.
