SharePoint 2010 allows the deployment of a solution package as a farm solution, (similar to how it works in SharePoint 2007) but it also allows the deployment of a solution package as a sandboxed solution, which reduces the scope of deployment from the level of the farm to that of a single site collection. Sandboxed solutions mitigate risk that custom code could cause and it does by restricting the API’s that can be called and governing resources that can be used.
Here are some interesting references:
MSDN: Developing, Deploying, and Monitoring Sandboxed Solutions in SharePoint 2010
Intro to SharePoint 2010 Development: How to Build and Deploy a Web Part
Eric Shupps on SharePoint 2010 Code Deployment, Part One
MSDN Sandboxed solutions
I read today the article of Dan Holme on delegating powershell access (click here for the article) and shared somehow his dissapointment. Briefly, in order to be delegated this role, the user must be a Site Collection Administrator (not just a site owner, member or visitor!) and have a db_owner role for the Content SQL database for that site collection. (SharePoint_Shell_Access role is nested into the db_owner role on the SQL side).
Definitely this is quite a very important barrier for rights delegation in Sharepoint and especially Powershell. Imagine that site owners/members could have used Powershell to script and automate some of their recurent tasks (site or content privisioning/update). But in this tiny detail, I see the importance of a good and comprehensive analysis of user needs at the very begining of a SharePoint implementation project. Product owners or Sharepoint architects might consider this in their planned architecture.
So be aware: If you already know or at least you anticipate that you might be called by your users to delegate them this role or to let them automate some recurrent tasks on the future Sharepoint 2010 farm, THINK now of building site collections instead of a tree of sites in the same site collection.
As it was said during a session on architecture at the Sharepoint Conference last year, site collections remain in SharePoint 2010 an important boundary and this not only because of the size of the content database and backup considerations. Now we have this access delegation which is extremely important in a corporate environment.
J’ai trouvé un article qui regroupe très bien 5 idées principales sur la nécessité de la mise en place d’une bonne gouvernance IT:
- L’alignement de l’informatique de l’entreprise sur les objectifs stratégique de l’entreprise.
- Gestion de la valeur ajoutée d’un service ou une application IT par rapport au business de l’entreprise
- Gêrer les risques
- Gêrer les ressources critiques (l’aspect humain avant tout)
- Mesurer les performances de l’IT
voici l’article: http://www.spiral.lu/cms/spiral/content.nsf/id/CMOT-7PUGJA?opendocument&language=fr
I installed Microsoft Office Sharepoint 2007 (MOSS) on a Small Business Server 2008. I configured the SSP and the search but the crawling did not start. Each time I started a Full Crawl, it ended up with the following error in the crawl log:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled. (The item was deleted because it was either not found or the crawler was denied access to it.)
At the same time the problem was that I could not browse to my Sharepoint Portal from within the IE of my server but I could do it without any problems from any other computer or from the Internet. This behaviour started immediately after modifying the default Alternate Address Mapping for my default web application: instead of the name of the server (e.g. http://companyweb) I had put the internet address (e.g. http://www.mycompany.com). (as a detail, I had also mapped my internet address to 127.0.0.1 in the local hosts file)
After some research I found that this error comes when you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer. It seems that this security protection is in place since IIS 5.1. So if I can not browse on the server to my own portal, neither the search service can do it (running as the same admin user)
Cause and resolution are fully described here: http://support.microsoft.com/kb/896861
Method 1: Disable the loopback check
Follow these steps:
||Click Start, click Run, type regedit, and then click OK.
||In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
||Right-click Lsa, point to New, and then click DWORD Value.
||Type DisableLoopbackCheck, and then press ENTER.
||Right-click DisableLoopbackCheck, and then click Modify.
||In the Value data box, type 1, and then click OK.
||Quit Registry Editor, and then restart your computer.
This worked fined for me but be aware that the Microsoft article proposes an alternative solution: Method 2: Specify host names
Solutions are there but nevertheless, I can not stop myself of saying that these solutions make Sharepoint server just a bit less secure, at least in he eyes of an security audit trail.
This blog post definitely help me in finding the right solution : http://svengillis.blogspot.com/2008/10/access-denied-when-crawling-moss.html
By default this feature is not enabled in SBS 2008, as Exchange and WSSv3 are installed on the same box. It can nevertheless be enabled by configuring an email domain to be used by the SharePoint site and a foreign connector on Exchange to take care of the mail routing (using Foreign Connector Cmdlets) to a drop folder (used by the SharePoint Site).
Configuring Incoming emails for Sharepoint on SBS 2008: http://www.mindwatering.com/supportref.nsf/c59b2b31baccdc2185256d4300106099/6cfe97df8868dc888525759e00217aa5!OpenDocument
About Exchange Foreign Connectors: http://technet.microsoft.com/en-us/library/aa996779%28EXCHG.80%29.aspx
About Foreign Connector Cmdlets: http://technet.microsoft.com/en-us/library/bb124003%28EXCHG.80%29.aspx
Below I found some related posts:
Here is an interesting post with complete instructions step by step from start to finish to configure an external device to use Exchange on an SBS in order to send emails to Sharepoint libraries: :
Configuring Incoming emails for Sharepoint on SBS 2003: