I don't know if I have caused this problem or something changed between B2TR and RTM, BUT:
Last tuesday while in the middle of a live demo at Microsoft's in The Netherlands I decided to create a mysite for the administrator. All of a sudden I was confronted with the error: 'Your personal site cannot be created because Self-Service Site Creation is not enabled. Contact your site administrator for more information.'
luckily I thought I saw a menu-item in Central Administration which was called 'site creation…something'. So I opened up Central Administration and in fact, at the Application Management tab I found the menu item called 'Self-Service Site Management'. Setting the option 'Enable Self-Service Site creation' (for the web application hosting the mysites) to 'allow' solved this error.
Phew….That saved my demo, so I didn't think anything more about it. Until this morning I got a call from a project team at Info Supports telling me they got this exact same problem. Same fix worked for them as well…but does anyone know what's causing this?
Perhaps it is because of the fact that Self Service Site Creation is not enabled, just guessing based on the error message. You even found the place where to enable it. Perhaps not a bug, but a feature?
wise ass 🙂
So, explain to me…why wouldn’t I want Self Service Site Creation enabled for My sites…since errr…that’s exactly what you want for ‘my sites’ 🙂
A bit wise-assish indeed, sorry for that. And why? Dunno, bumped into this myself as well. Perhaps to allow admins to set up mysites instead of users themselves. But then again, I just dont know…
BTW, that is not a spam post. The url explains why it is disabled by default.
Thanks for the link. However it is still unclear to me why this isn’t enabled ‘by default’ when I create the web application which hosts the my site.
For all other readers: The link netdevil posts is very helpful to learn the differences about creating sites from Portal 2003 or a MOSS 2007 portal.
Perhaps having automatic site creation disabled on My Sites is a good thing. In my case, I have clients that want to control who has a My Site. This may be because they are not ready to unleash this new technology on all authenticated users, or because they only purchase a set number of licenses. If it was enabled by default it would be possible for any authenticated user to create a site before an implementation was completely configured.
Thanks for your response. What you are describing is taken care of with setting the appropriate security for users. This way you can enable some users to get a mysite and others get a ‘personal page’.
So, this is not the answer to my question. What’s even more weird, is the fact that this just pops up randomly…most farms I installed had in activated by default so no problems there….
But thanks again for thinking with me 🙂
It’s probably set to no by default because otherwise everyone who had access to one of your sites could also automatically create a MySite for himself. As this might cause problems in your network it’s safer to set it to no by default.
(It also imposes on adminstrators to think about the option of using it wisely)
Maybe its like this by default because the architect was playing scrabble on facebook during team meetings
I dont think you have to turn on ‘Self-Service Site Management’ for the web app that is hosting My Sites. On our MOSS Farm it is turned off by default and I can create My Site just fine.
Having said that i have another dev Farm where I got the same error mentioned above and it did worked by turning on ‘Self-Service Site Management’. So something definitely happened in the system that is now making it necessary to have ‘Self-Service Site Management’ service turned on to create My Site.
if anyone has any idea?
None of these is the correct solution. Self-Service Site Management should never be enabled unless very specifically required. Below is the process for correctly resolving this problem.
Chris Chapman, MCT, MCITP
Correction, a period has to be included at the end of the url above:
Chris Chapman, MCT, MCITP
Thanks for your comment. I however do not agree with your solution. Enabling Self Service site creation for one web application feels a lot more secure to me then adding the application pool account to the farm administrators group.
Secondly, enable self service site creation is something that can be done by farm administrators while adding users to AD Groups is something that has to be done by domain admins. So you also got maintenance roles involved here.
That would be true except that the app pool account is a service account that I create, that SharePoint® automatically manages permissions for, so I know that it is configured as it should be and as designed for this solution.
Also, if you don’t use service accounts, the use of which is best practice, then SharePoint® automatically uses the Network Service alias as the service account for the app pool that SharePoint® also automatically creates for your default site collection. This account allows the creation of mysites without either enabling self-service site creation or adding the service account to farm admins. This implies that the addition of the service account to the farm admins is indeed the preferred method, as when you do a default install of SharePoint®, mysites creation works without enabling self-service site creation, as intended.
There are reasons for not enabling self-service site creation at all:
1) It won’t work if you are using host headers or if you are in AD Account creation mode.
2) You are now creating multiple site collections in a single webapp instance that can interfere with each other. This also creates a problem for error logging.
3) Each site collection created will automatically inherit quota limits, which may or may not be configured by the admins for this purpose. You will also have to use central admin to constantly monitor the various site collections for size.
4) You have to be an admin to get into Central Admin to monitor and maintain site structure if the site collection creation gets out of hand. You can’t have a site collection admin use the SharePoint® site Structure and Content tools to monitor and manage sites at all.
Normally, SSC is ENABLED by default for the mysites web application. This blogpost is about the fact that it sometimes isn’t, which is weird. Also, the app pool account for SSC isn’t a member of the Farm admins by default.
But, curious as I am, I tested your solution. I removed the SSC enabled option from the webapplication which hosts the my sites and added the app-pool account from the IIS website to the farm administrators group. Hereafter, the mysite for a user is created so your solution does work.
Still, I feel you should never ever give a service account farm administrators rights when it only needs functionality on a web application!
I’ve been searching in the ‘plan for administrative and service accounts’ article on Technet (http://technet.microsoft.com/en-us/library/cc263445.aspx) but nothing there is saying I need to add the app-pool account to the farm admins group.
Can you show which resources you found which say it has too?
I also would like to react on your 4 bullets about SSC:
I think you mean hostheaders for site collections here, it’s perfectly ok to use hostheaders for your web apps and use SSC. The default SSC application page does not have the option to specify hostheaders for site collections, the API does support this and you can create your own SSC application page which makes use of this.
How can multiple site collections interfere with eachother on a web application? You are only allowed to use a site collection name once and this is check on creation time. I don’t follow..
For my sites, this is definitely what you want. Set up a quota for my sites and let your users take off. If they run out of space or into trouble they can seek assistance with IT, but in the meantime they are free to do what they want.
The site structure and content tools are meant to be used inside a site collection. My Sites are actually ‘My Site Collections’ and the structure and content tools can be used by your my site users to maintain their own site collection. They aren’t designed to be used by IT admins to keep an overview over all the site collections on a web application.
I only have one refute to that last post. SSSC is NEVER enabled by default, on any web application. I am no longer going to continue this post, as I was just relaying useful information and you insist on a fight.
I know my solution works. I also know that SSSC is not enabled by default on any web application, ever.
Please do let me know if you need any other sharepoint tips.
I’m sorry you feel that I’m insisting on a fight. Actually, what I am doing is critically looking at the solution you provided for a problem I already encountered in March 2007.
My question if you could refer me to your resources was genuine, and I tested your solution myself to see if it works…what else do you want me to do? I believe in giving service accounts the least amount of privileges possible and do teach this in my classes. (I am an MCT myself).
If you can prove to me your solution is the right one, I’ll incorporate it into my class and even give you credit for it. However, I remain sceptical until that time and stick to my own opinion on this.
You can do the same for your opinion and that’s allright with me, but by discussing things like this on blogs, ultimately the community benefits.
So I would like you to reconsider and continue this thread. Let’s find the proper solution to this!
Sorry, but I believe the solution of making the service account a farm admin highly misplaced. You basically say that instead of clicking ‘enable self service site creation’ you should make some account farm admin to achieve the exact same goal. How does that help? With a click you only get SSSC, and in your solution you get SSSC plus a new farm admin. Seems overdoing it generously.
The advice to remove security messages by making someone admin is not the route to take anywhere in SharePoint.
On the other points raised, I think you are mistaking a my-site for a site, it is a site-collection that gets provisioned (I believe *always*, but excuse me if I am wrong).
Wouter van Vugt
Chris is correct in that this is the recommended fix. If you enable self-service site creation, you in effect allow regular users to create and administer site collections. Not only does this give the users more access than they need, it also adds to the administrative overhead for those whose job is the administration of SharePoint.
Creating a service account, as Chris recommended, is the best practice. You are not “making someone an admin”; you are creating a service account for a service, as you would do for any service within the Windows operating system.
Anwar Habibish, Microsoft SharePoint Development Team
Bart and Wouter,
I am also for continuing and coming to a great conclusion for the benefit of many students.
I only have one retort. If SSSC is the way to go, why is it NEVER enabled by default in any web app in any sharepoint install. But, I can still create MySites, if I have used the basic install option? Or if I have used the advanced install option and given my webapps preconfigured service accounts (for example, Network Service)?
If your solutions were correct (despite that fact that they do work), this would be the DEFAULT setup of sharepoint, and it isn’t. The only time I can’t create mysites without either using your or my solution is when I have used custom service accounts. And to most closely follow the method that the sharepoint install itself uses, I wouldn’t enable SSSC.
Enabling SSSC gives every user in my organization an administrative ability. The ability to create site collections. Not mysites, but entire site collections.
If I haven’t created a separate webapp for mysites, this means anyone can create any site collection in my main webapp.
Also, service accounts are meant for priviledges. That is what protects the entire setup. This prevents you from having to give your users the above mentioned admin ability.
Thank you for commenting on this discussion.
Chris and I are going to look into this a bit further, however could you shed some light on WHY it’s necessary to give the app-pool account farm admin rights?
And where does it say it has to be like this in the documentation? I still can’t match this on the ‘least privilege’ principle, that’s why I’m so critical on this.