SPBasePermission

While my friends were having fun during weekends, I was hitting my head against an issue in my application. It took me a very long time to understand and resolve the issue. But finally all well that ends well. Here is the issue. I use Visual Studio for creating a subsite under a site collection. The users are present in the site collection under "Read" role. I use impersonation to create the subsite. After creation of site, I create RoleDefinition and the RoleAssigment so that the users have all appropriate rights on the newly created subsite. I was properly breaking inheritance by using web.RoleDefinitions.BreakInheritance(false,false); The above statment was written to ensure that the "Read" role permissions are not carried over to subsite, instead subsite should use their unique permission level and unique role definition. The problem was, after creation of subsite the subsite was not accessible to the users in the specified group. Inspite of all above written measures, I was not sure what is causing this error. After trying lots of things finally I got the solution. The solution was simple as to have following permissions applied to the RoleDefinition at the time of creation SPBasePermissions.ViewListItems SPBasePermissions.AddListItems SPBasePermissions.EditListItems SPBasePermissions.DeleteListItems SPBasePermissions.OpenItems SPBasePermissions.ViewVersions SPBasePermissions.DeleteVersions SPBasePermissions.ViewFormPages SPBasePermissions.Open SPBasePermissions.ViewPages SPBasePermissions.BrowseDirectories SPBasePermissions.BrowseUserInfo SPBasePermissions.UseClientIntegration SPBasePermissions.UseRemoteAPIs SPBasePermissions.CreateAlerts SPBasePermissions.EditMyUserInfo; That resolved my issue. If anybody has same or similar issue, let me know. I would be happy to assist. Thanks, Subhash

Remember this while upgrading from WSS 2.0 to WSS3.0

In this article we would try to figure out few small things which you must remember before/during an In-place upgrade from WSS 2.0 to WSS 3.0. 1. Connection strings/ connection string information: If you have a custom application running under a sharepoint site, make sure that you do not have connection string like "Data Source=(local);Initial Catalog = MyDB;....." etc. This is because the upgrade might fail because of the word (local). Same is applicable to your settings in Sharepoint Central Administration. Make sure that Content/configuration Database server name is not (local) or . Even if you are using local server as database server, make sure you give Full Name. 2. Prescan-tool: After the last step of Installation of WSS 3.0, the installation wizard have one check-box for executing Sharepoint Technology Configuration Wizard. This check-box is checked by default. However the upgrade would fail if you continue as is. Ensure that you have executed Pre-scan tool before execution Sharepoint Technology and configuration wizard. The prescan tool exists under programfiles/Microsoft Shared/Web server extension/12/bin directory. 3. Rights: Make sure that the service accounts are set properly and that these accounts have all required access to all servers and to the database. In the unfortunate even of upgrade failure, don't worry. Just visit upgrade log available under programfiles/Microsoft Shared/Web server extension/12/logs. Understand the exception and act accordingly. Though wizard states that the process is irriversible, you can always correct the issues and execute the wizard again. In most of the cases, the upgrade fails because of few obvious reaons. Enjoy !! Subhash

System policies must have full control !!

I have been trying hard with a problem with the search service. Here is the problem definition. While using Windows Sharepoint Services 3.0 Search Service, when you try to start the search service instance on webserver, it throws error "System policies must have full control". And this is the solution that worked for me: I digged into all kind of books, technical references. There may be several different reasons behind this error and solutions defer from situation to situation. But the in my case problem was with the Service Account and Content Access account. I was trying to start the search service using credentials of Farm Administator. However it has been explicity mentioned on Microsoft Techcenter, that the content access account and service account MUST NOT BE farm administrator. I got this reference from here: http://technet2.microsoft.com/Office/en-us/library/f07768d4-ca37-447a-a056-1a67d93ef5401033.mspx?mfr=true . I just created a seperate domain account and used that as service & content access account. That's it!!! The search service started working very smoothly. Hope this helps you. Happy programming :-) [Please note: This solution/comment is based on personal experience and may not be authentic. This solution does not guarantee that it would react the same way anywhere else. You can refer to product documentation and authorized websites for more information.]