MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

MySite config frustration

  Asked By: Thaddeus    Date: Mar 07    Category: MOSS    Views: 1364

We're now on our 3rd MOSS farm
install/configuration after failing on the first two. *sigh*.

This time, things were going pretty well. We finally have SSL working,
and have had enough practice (or so I thought) with the previous two.
This time, I got hung up on mysite configuration, though. On the
previous farm, we actually made a separate web application and pointed
a URL at it, but I tried not doing that this time.

In summary, we have a top level site collection, with other site
collections appearing 'under' it via managed paths. I went to set up a
new site collection for MySites, gave it a managed path, then tried to
configure that in the MySite settings under the SSP. Alas, upon doing
that, it appears that the root collection now it trying to redirect to
the mysite with errors. Here's the details:

We have a default/top level site collection at '/' so, that would
resolve to this:


We then set up a new managed path /mysite and then set up a new site
collection using that path at /mysite:


in SSP Administration, under TRUSTED MY SITE LOCATIONS, we entered that url:


and, finally, in My Site Settings, under personal site provider, we used:


and under PERSONAL SITE LOCATION, we put:


Then we navigate to our mysite:


(notice a pattern ;o)

and get met with this error:

"Your personal site cannot be created because the managed path
"https://ourSharePointDomain.com/mysite" has not been created for this site.
Contact your site administrator for more information."

Anyone see anything wrong with our configuration? Any obvious
misteps/oversights on my part? I'm thinking I'm not supposed to put
the /mysite URL in all of the mysite config fields.



16 Answers Found

Answer #1    Answered By: Duane Walton     Answered On: Mar 07

From what you discribed it sounds like you created  an "Explicit
Inclusion" managed  path, I am not sure if MOSS will use that. By
default the MySite managed path  is a "Wildcard Inclusion" so that
each MySite that is created is its own site  collection, with
an "Explicit Inclusion" managed path you can have only one site
collection so if the MySite creation process only created a site
collection and not a site in a site collection  it will fail.

Answer #2    Answered By: Cassandra Cooper     Answered On: Mar 07

After more reading, I think I need to step back and maybe ask a
bigger-picture question.

For starters, should mysites  be hosted by it's own web  application?

I came across this post:


Which I followed, and seems to work, except that it prohibits a person
from creating a site  as I don't have self-service site creation
enabled. From a governance standpoint, I don't think we want to enable
it at the web application  level for all site collections. As such, it
sounds like we really need to host mysites in a separate  web

Answer #3    Answered By: Elaina Suarez     Answered On: Mar 07

Best practices says that it should be on its own Webapp...

Answer #4    Answered By: Kacey Russo     Answered On: Mar 07

Depending on how many users you have that will have My Sites and what
quota you set  for them, also make sure to create enough content
databases to keep your DBs at a reasonable size. Otherwise they'll
all end up in the same default DB that was created  at the time  you
created your web  app. Fortunately, this isn't as big of a deal as it
was in the past, but its still nice to set it up right the first

Another random thought: If you have a lot of users/My Sites, you can
script the creation of sites up front so you aren't creating a bunch
of them all at the same time during the day. site  creation can
affect performance in some cases.

Answer #5    Answered By: Rebecca Lewis     Answered On: Mar 07

I wish MS would put  Best Practices into its own documentation. ;o)

Thanks for the confirmation!

OK, off to the next challenge...figuring out how to get two web  apps
both running on SSL on the same farm...

Answer #6    Answered By: Emily Clark     Answered On: Mar 07

The MS Press Best Practices book will be out soon.

Answer #7    Answered By: Alycia Everett     Answered On: Mar 07

35625387, in case you were interested

Answer #8    Answered By: Kaila Hahn     Answered On: Mar 07

I our environment we are hosting five web  applications all using SSL
including Central Admin. The only way to get this to actually work
with all of them using port 443 was to have 5 separate  IP addresses
on each of the WFEs and then to go into IIS for each of the web
applications and change IP address assigned to the web app
from "(All Unassigned)" to a specific IP address.

Even though IIS can separate different web applications using Host
Headers for non-SSL sites it can not be configured to do it when SSL
is being used.

Answer #9    Answered By: Ada Sosa     Answered On: Mar 07

That is correct, you cannot use host headers with SSL. Well, you could have used
wildcard cert, but that's kind of hokey.


Answer #10    Answered By: Cheyenne Lewis     Answered On: Mar 07

Host headers will function with SSL, but they require special configuration  in
IIS 6.0. See the following article.


Answer #11    Answered By: Liana Alston     Answered On: Mar 07

We have our own PKI infrastructure and use the "Subject Alternative
Name" field in our certificates to allow us to use only one
certificate for all of the SSL sites on a shared server.

For example if we have a server with a FQDN of wfe1.company.org
hosting the sites webapp1.company.org and webapp2.company.org we
would put  wfe1.company.org in the subject field of the certificate
and DNSName: webapp1.company.org; DNSName: webapp2.company.org in
the "Subject Alternative Name" field of the certificate.

Do you know if this would work with the SSL host header
configuration described in the article instead of the wildcard

Answer #12    Answered By: Daamodar Kolhe     Answered On: Mar 07

OK, I have set  up a test where I setup three SSL sites. Two of the
sites use the SSL host headers and the third uses a separate  IP

It works as advertised with one minor issue. If you update the
certificate once you have the SecureBindings set with the host
header info you will lose the host header info and have to set up it

Answer #13    Answered By: Emerson Franks     Answered On: Mar 07

I don't really know, but the only solution's I've ever seen for this all use a
wildcard certificate.

Answer #14    Answered By: Ned Storm     Answered On: Mar 07

I asked a question yesterday regarding this and completely hadn't
noticed that this thread had gone on with more details. So, yes, all
this feedback definitely answers my question. In summary:

mysites  should be their own web  Application because:
- multiple web apps can reference the same mysite  then
- you need to turn on Self Service site  creation, and likely don't
want that for your other web apps
- Running it with SSL along anotehr SSLed web app requires either:
- multiple IP addresses and modifying the IIS IP settings  or
- wildcard SSL certs and modifying the host headers in IIS.

I think the only remaining question was a followup to the advice that
one set  up enough DB's for MySites so that one doesn't get overly
large. How is that done? We've set up mulitiple DB's per web app, but
each siteCollection only has one DB. Is it bad to run all MySites in
one DB?

Answer #15    Answered By: Myron Calhoun     Answered On: Mar 07

I've actually accomplished this via distinct IP addresses for each
site. I've my portal accessible via https:// on one IP and my My Site
site collection  on another/different IP, also accessible via https://

Answer #16    Answered By: Rena William     Answered On: Mar 07

In our implementation we have MySites on its own Web Application for
the exact reason that you need to have Self Sitecreation turned on.

Didn't find what you were looking for? Find more on MySite config frustration Or get search suggestion and latest updates.