Security trimmed SiteSettings page

A couple of days ago I posted about the "Manage web site" option in the "User Permissions for Web Application" section of the Central Admin. If we unchecked that option we saw that a lot options disappeared in the Site Settings page for users who have Full Control and this was the desired case in our environment. Unfortunately a lot of unexpected errors occurred because of the removal of permissions. Not only the permissions were removed from the users but also from the service accounts on which SharePoint runs. So the conclusion was to enable it again to maintain functionality and just have to deal with less strictly managed sites.

But! Today I found the solution.. it seems that the Site Settings page is just a feature as well and you know what you can do with links that are controlled by features.. Yes! You can security trim them! So in order to remove the links from the Site Settings page you just open the sitesettings.xml (\12\TEMPLATE\FEATURES\SiteSettings) and the following bit to each link : 'RequireSiteAdministrator="TRUE"'

So the 'Site Features' link (one of which we don't want the user to play with) looks like this:

<CustomAction
        Id="ManageSiteFeatures"
        GroupId="SiteAdministration"
        Location="Microsoft.SharePoint.SiteSettings"
        RequireSiteAdministrator="TRUE"
    Rights="ManageWeb"
        Sequence="80"
        Title="$Resources:SiteSettings_ManageSiteFeatures_Title;">
        <UrlAction
            Url="_layouts/ManageFeatures.aspx" />
    </CustomAction>

 

And here is the tricky part.. at least.. it feels really tricky.. you will have to uninstall the site settings feature using STSADM and install it again for the settings to take effect

STSADM -o uninstallfeature -name sitesettings
STSADM -o installfeature -name sitesettings

There you have it! A trimmed Site Settings page without having to unchecking the 'Manage WebSite' option. Although with URL hacking you can get there ofcourse so it's not really bulletproof (although, you can edit the .aspx pages and put a SPSecurityTrimmedControl around it)

SPGridview and collapsed grouping by default!

This really bugged me when I came across the SPGridView (as you can read in the previous about this control) that when you set the following properties

oGrid.AllowGrouping = true;
oGrid.AllowGroupCollapse = true;

You'd expect that there is another property where you can specify if you want to have it collapsed or expanded when the Grid gets rendered. Unfortunately there isn't.. but (and that's why I'm posting ;)) there is dirty way to do it and that's injecting some javascript after the grid gets rendered. Thanks to my collegua Servé "CSS/HTML & Javascript Wizard" Hermans the following bit of script gets the job done.

<script type="text/javascript">
var rows = document.getElementsByTagName('tr');
var numRows = rows.length;
for (var i = 0; i < numRows; ++i) 
{
    if (rows[i].getAttribute("isexp") != null && rows[i].getAttribute("isexp").toLowerCase() == "true")
    {
          if(rows[i].firstChild.firstChild != null && rows[i].firstChild.firstChild.tagName.toLowerCase() == "a")
          {    
              if (rows[i].firstChild.firstChild.title.toLowerCase() == "expand/collapse")
                  {
                    rows[i].firstChild.firstChild.fireEvent("onclick");
            }
          }
    }

}
</script>

To explain it the script.. an event called "ToggleSPGridViewGroup" (which can be found in the spgridview.js in the Layouts folder) is fired when you click on the expand/collapse icon on the grouped item. So I thought "Why not fire all of the links to have it all collapsed by default?" :) I thought this wasn't possible since it seems REALLY dirty to actually fire events without user interaction. But it actually is possible! Thank god ;)

Technorati tags: MOSS. Development, WSS

Self-Service Site Creation and permissions

Yet again a post about permissions! This one is about the self service site management feature that you can enable in the Central Administration page near the Application Management and then right here :

So you enable it and click on "OK" just like the screenshot below :

Next you want to create a site using the 'scsignup.aspx' page and there you get an access denied error and SharePoint wants you to login with a user who has sufficient permissions to perform this action. So I checked the eventlog for any errors and found the following :

The site /sites/<sitename> could not be created.  The following exception occured: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

And then it hit me.. we unchecked the "Self-Service Site Creation permission" in the "User permissions for web application" (see screenshot below at the bottom) :

So I checked it and tada! We could create sites using the Self-Service Site Creation page!

Now this all makes sense ofcourse although I figured that once you enabled it, the permission would be turned on automatically or an error would be raised to inform you that you need to make sure that the permission is set.

Hopes this helpes someone ;)

 

Technorati tags: MOSS, Support

Permissions and workflow

In our environment we unchecked in the 'User Permissions for Web Application" the following option "Manage Web Site  -  Grants the ability to perform all administration tasks for the Web site as well as manage content. " By doing this we see the following difference in the Site Settings page :

Manage Web Site : Checked

Manage Web Site : Unchecked

So if you see the 'unchecked' sitesettings page, a site owner for example cannot manage features or delete his own site. This is in our environment is very desirable since site owners are not administrators but 'just' users. Therefore giving them the least amount of privileges is a must (so they can't destroy their own site ;)). It's like deploying workstations and giving the user not administrators permissions on their desktop.

But! When a user is trying to start a workflow the keeps getting the "Operation in progress' screen and in the eventlog of the front-end server the following error occurs:

Event code: 4011
Event message: An unhandled access exception has occurred.
Event time: 8/27/2007 8:23:07 AM
Event time (UTC): 8/27/2007 6:23:07 AM
Event ID: 14b3855a81684973a4ede892d8c82298
Event sequence: 354
Event occurrence: 2
Event detail code: 0
Application information:
    Application domain: /LM/W3SVC/1574755854/Root-3-128326491020874251
    Trust level: Full
    Application Virtual Path: /
    Application Path: d:\Inetpub\wwwroot\wss\VirtualDirectories\80\
    Machine name: <machinename>
Process information:
    Process ID: 2280
    Process name: w3wp.exe
    Account name: <accountname>
Request information:
    Request URL: <url>/_layouts/IniWrkflIP.aspx?List=5fa2c8f9-d6df-4ba5-af1c-960cab0b15d5&ID=4&TemplateID={463a6ced-0731-4180-9626-2ccce20551a7}&Source=<url>
    Request path: /_layouts/IniWrkflIP.aspx
    User host address: 172.16.46.2
    User: <accountname>
    Is authenticated: True
    Authentication Type: Basic
    Thread account name: <accountname>

So what does this say? Well, it tells you that the process hasn't got sufficient permissions to perform the action. So if we check the option "Manage Web Site" again, the error won't be raised and the workflow will work just like it should. In my opinion this is bad.. very bad.. I reckon that the process accounts (and thus the System Account) should be excluded from the Web Application permissions set. Since you assign permissions to the users of the web application instead of the system accounts.
And yes.. I have also set the service accounts having Full Control in the Policy for Web Application pages.

So if someone has the answer, let me know ;)

 

Technorati tags: MOSS, Support

QuickLaunch and workspaces

Ever noticed that you don't have the QuickLaunch available when working with (meeting) workspaces in 2007? Even though you checked the option to enable it, it's still not there! Well fear not since Servé Hermans made it visible.. how? Well read it at : How to enable Quicklaunch on multipage meeting workspace  and you might having this as well, pleasing yourself and your users in the quest for more userfriendliness;)

Technorati tags: MOSS, Customize

Picture library and unsafe updates?!

In addition to my other post about the infamous message from SharePoint: "Updates are currently disallowed on GET requests.  To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb."  I came across this error in a rather unusual place and that's the one where you click on a picture in a picture library to show the complete image in the browser.

This occurs if you have the following configuration :

IIS : Virtual server  is running in SSL and basic authentication
SharePoint : made a change to the web.config to enable blobcaching (as you can read here to improve the performance of your environment)

When I accessed the environment using Windows Integrated security I did not receive an error. The same applies when I used basic authentication and disabled the blobcache.

Hope this helps someone!

 

Technorati tags: MOSS, Support

Exception from HRESULT: 0x80041050

I got that error when I opened up our beautiful migrated production environment. First thing I tested was to check if every site had the error.. weird thing was that only a couple of sites had that error. So (obviously) I ran the error in Google and found the following blogpost : Forefront Security and MOSS ( Exception from HRESULT: 0x80041050) by MOSS Paradox which give me the source of the problem and the solution :) It seems that ForeFront (the new (and only) antivirus tool for SharePoint 2007) didn't like some of the files that were in our environment and instead of displaying a nice and userfriendly error that a "Virus was found, so therefore access to the site is blocked" we get the "Exception from .." error.

Fortunatly there were no viruses, so we changed the configuration of ForeFront to be less restrictive. Enabled only three virusscanners instead of five and changed the bias settings to 'max perfomance'.

Also before I googled for the solution I found that opening the central administration page took ages! No matter how many browsers I let connect to the admin page none of them could get access. Until I did an IISRESET and then before the service was stopped, the central admin page opened. So I checked out the eventviewer and found that ForeFront was reporting errors like "SharePoint Realtime scan exceeded the allowed scan time limit" and "Scan/Clean document <filename> failed due to timeout error".  Then I tried to stop the ForeFront services and they couldn't be stopped in a timely order fashion. After the services had stopped, the central administration page was accessible again. Then I went into the configuration page of ForeFront and there I unchecked the option that the 'SharePoint Realtime scan job' scans documents on download. '

By doing this configuration and mostly due to unchecking 'scan documents on download', our environment was suddenly a lot faster as it were using the default ForeFront configuration.

 

Technorati tags: MOSS, ForeFront, Support

Current Navigation, Global Navigation, siblings and PublishingWeb?

Yes yes.. that's what was in my head during my quest to change the following options in the Navigation page.

I managed to change the global navigation use the following code:

web.Navigation.UseShared = true;
web.Update;

So how do you change the current navigation? Well, remember that the 'Navigation' link only becomes available when you activate the Office Sharepoint Server Publishing Infrastructure feature? Searching the online SDK I found the following class : PublishingWeb. This class which uses SPWeb has the following property : NavigationShowSiblings. When you set this boolean to true, the current navigation section will change to the desired option (as selected in the screenshot)!

Together with my colleague Servé Hermans we (indepently) searched for the solution and it was quite scary when I found the solution he also, at the same time, found the same page and thus the solution ;)
 
You might wonder why on earth we want to do this programmatically.. well we are working with a migrated environment where we are replacing our custom navigation webpart with the quicklaunch showing all the subsites (securitytrimmed ofcourse!). In order to make this work properly we have to set all the individual subsites to use that 'current navigation' property. Basically the code looks like this :

SPSite site = new SPSite("http://<sitename>");
foreach (SPWeb web in site.AllWebs)
{
    try
    {
        if (PublishingWeb.IsPublishingWeb(web))
        {
            PublishingWeb publishingWeb = PublishingWeb.GetPublishingWeb(web);
            publishingWeb.NavigationShowSiblings = true;
            publishingWeb.Update();
        }
    }

    catch (Exception error)
    {
        Console.WriteLine(error.Message.ToString());
    }
                     
    web.Close();
    web.Dispose();
}
site.Close();
site.Dispose();

Technorati tags: MOSS, Development

Custom action locations and groupid's

I've been wandering around the internet to find all the locations that you can define to add your custom action at. You see, I want to add a link near the 'Welcom <User>, My Site, My Links' section (aka the global links section). What I found was the following :

Using CustomAction to modify system pages by Chris O' Brien

• Microsoft.SharePoint.ContentTypeTemplateSettings
• Microsoft.SharePoint.ContentTypeSettings
• Microsoft.SharePoint.Administration.ApplicationCreated
• Office.Server.ServiceProvider.Administration (Shared Services/SSP links)
• Microsoft.SharePoint.ListEdit.DocumentLibrary
• Microsoft.SharePoint.Workflows
• NewFormToolbar
• DisplayFormToolbar
• EditFormToolbar
• Microsoft.SharePoint.StandardMenu (SiteActions menu)
• Mcrosoft.SharePoint.Create (_layouts/create.aspx - the screen used to specify what you want to create on your site)
• Microsoft.SharePoint.ListEdit (the screen used to edit the properties of a list item)
• EditControlBlock (image below)

That's more than Microsoft specified on their page How to: Add Actions to the User Interface. But still I didn't found my answer on how to add a link to the global links section. Then I went looking in the 12/Templates/Controltemplates folder for the usercontrol that renders the 'Welcome <User>' section, named "Welcome.ascx". There I found the following bit :

     <SharePoint:FeatureMenuTemplate runat="server"
         FeatureScope="Site"
         Location="Microsoft.SharePoint.StandardMenu"
         GroupId="PersonalActions"
         id="ID_PersonalActionMenu"
         UseShortId="true"
         >

Now it's the GroupId that interested me.. So I created a feature that looks this (first part being the feature.xml and the second being the elements.xml) :

<Feature 
  Id="AA929AFF-4602-4d7f-A501-B80AC9A4BB52" 
  Title="Add Links to user section"
  Description="Feature that adds a link to Welcome User section"
  Scope="WebApplication" 
  xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="Elements.xml" />
  </ElementManifests>
</Feature>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <CustomAction 
        Id="0acdbd94-eba8-11db-8314-0800200c9a66"
        GroupId="PersonalActions"
        Location="Microsoft.SharePoint.StandardMenu"
        Sequence="1000"
        Title="View Terms of Use"
        Description="Open the Terms of Use document"
        ImageUrl="_layouts/1033/images/KpiListView.png">
        <UrlAction Url="_layouts/termsofuse.aspx"/>
    </CustomAction>
</Elements>

 

So how does that look in real life I hear you wonder... well like this :

 

Technorati tags: MOSS, Features

Failure trying to synch web application

During a migration you sometimes delete a webapplication, create a new one.. attach the migrated content database and delete the webapplication again and so forth..
By doing this you suddenly get errors in the eventlog that looks like this :

Failure trying to synch web application 0ae4e145-5739-4d22-9a55-a05be465fb4e, ContentDB c7e4abe7-a670-4b7d-9350-c6105e4126ba  Exception message was A duplicate site ID 1680b2b0-e207-4aac-8dc2-72c9eb33812f(http://sitename) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

Fortunatly the problem solving was done using the first link that popped up in Google and that was the following : Gotcha When You Attach a New Web Application to an Old Content Database in SharePoint 2007 by Grant Earl.

Thanks Grant!

 

Technorati tags: Support, MOSS, WSS

I (L) SPGridView

Currently I'm busy with redeveloping some 'old' 2003 webparts and quite often I used a .NET datagrid to display data. Now with SharePoint 2007 we have to ability to render our data using the SPGridView. Using this control, you don't have to worry about to set CSS classes since it inherits the default SharePoint CSS so that's prety cool.
Another cool thing is that you can sort and filter like you sort and filter in SharePoint lists, although I haven't  got the filtering working, the sorting is quite cool. Even more if you use the AJAX Basewebpart by .. to make it even more sexier ;)

Check out the following links that helped me these last couple of days!

SPGridView thingies:

Filtering with SPGridView by Bob's SharePoint Bonanza

SPGridView and SPMenuField: Displaying custom data through SharePoint lists by Powlo's SharePoint Treats

SPGridView- Adding paging to SharePoint when using custom data sources by Powlo's SharePoint Treats

 

Ajax thingies :

AjaxBasePart- Easy ASP.NET 2.0 AJAX Extensions 1.0 and Office SharePoint Server 2007 by Eric Schoonover

Wait a sec!! by Adam Semel's ASPNET Blog

Using a SPGridView inside an ASP.net Ajax UpdatePanel by Mark Collins

 

Technorati tags: WebParts, AJAX, MOSS

Office Sharepoint Search Scopes and SSL

To come straight to the point, I had problems using the contextual search scopes from Office SharePoint Search (also known as This Site : <SiteName> and This List : <List Name> scopes). Problems being that I didn't get any searchresults. I did get search results however when I used the All Sites scope.
So far I didn't mention that the site was using SSL and during the creation we choose that the site was using SSL.  This implies that the site can only be accessed using the SSL port (and host-header). This is the point where (our) shit hits the fan.. So I created an alternate access mapping to make the site accessible from within our network and created a searchscope using this address. When I used this scope I received the searchresults I wanted. Unfortunatly the "This Site" scope didn't work and not wanting to create a custom searchscope for each individual site I tracked the problem down to the SSL thingie.

So I performed the following steps to fix this problem :

1. Deleted the webapplication leaving only the content databases
2. Created a new webapplication using the local address as default zone
3. Added an alternate access mapping in the extranet zone of the newly made webapplication
4. Added the SSL certificate in IIS and modified the hostheader.
5. IISRESET

And voila.. my OTB contextual searchscopes were working! :)

UPDATE 5 SEPT 2007

Below is a more detailed overview of the steps to make it all work by Glenn :

1. Obtain a wildcard SSL Certificate for your external domain name and install it. E.g. if your external domain name is MyBusiness.com then you would need an SSL certificate for *.MyBusiness.com
2. Install Sharepoint 3.0 in side by side configuration with the existing version 2.0 as per the document at this link: http://www.microsoft.com/downloads/details.aspx?FamilyID=0DAAFC81-EFFF-4F5B-A28A-8265F1E99F5B&displaylang=en
3. Configure sharepoint/SBS to enable the search feature on the farm (this may require a little googling as I can't remember where I found this).
4. Create a CNAME DNS entry on your DNS server, in 'Forward Lookup Zones/MyInternalDomain' for what will be your internal access url; e.g. http://sharepoint would require a CNAME entry of 'sharepoint', pointing to the appropriate Host record.
5. Create a CNAME DNS entry on your DNS Server, in 'Forward Lookup Zones/MyDomain.com' for what will be your public access url; e.g. https://share.mydomain.com would require a CNAME entry of 'share' pointing to the same Host record as in step 4. Don't forget to add a similar record to your ISP's DNS listings if you use an ISP for your public DNS record hosting.
6. Create your Web Application in Central Administration using your internal url; e.g. http://sharepoint on a NEW virtual server (i.e. DON'T use the existing 'Default' instance) but DO put it on port 80 (if thats what you want) as long as you enter 'sharepoint' (or whatever you used in step 4.) as the Host Header. Don't forget to run 'iisreset /noforce' on your web server after creating the Web Application in Central Administration. Do use NTLM authentication - I haven't tried Kerberos and don't know how this would be done.
7. Extend your Web Application to a NEW virtual server, also running on port 80. Once again - do use NTLM authentication. Enter the Host Header as per your chosen external url in step 5. E.g. share.mydomain.com Do choose 'Use SSL'. Yes, I know I am skipping some other settings here, but they are relatively self explanatory.
8. Once this is created, switch to IIS and you will see that your new external website is there, but it will likely be stopped with some nasty error message. Don't worry, just bring up the website's properties and make sure that SSL the port is set to 443, also check that the Host header value is set properly (it is blank on our machine when I do this - but it should be whatever you entered in step 7.).
9. Also, while in the website's properties, assign the wildcard certificate that you obtained in step 1. to this website. The website will still be stopped at this stage. Thats OK, we aren't ready to start it yet.
10. Set the SSL host header on your external website by doing the following:
1. Start a command prompt and change directories to C:\Inetpub\AdminScripts
2. enter the following 'cscript adsutil.vbs set w3svc/websiteID/SecureBindings :443:HostHeaderName' where websiteID is the Id number of the website as listed in IIS and HostHeaderName is the same host header that you entered into the properties for the website in IIS in step 8. and 7.
11. While your in the command prompt hit F3 to repeat what you just ran and change it so that you have 'cscript adsutil.vbs set w3svc/websiteID/AccessSSL TRUE' and run it. Note that this is optional - all it does is force people to connect using https.
12. You should be able to right click the website now and select 'Start' and it should do so without error.
13. In Central Administration, under Operations>Alternate Access Mappings make sure that you have two mappings present:

Default Zone:
Internal URL: http://sharepoint
Public URL: http://sharepoint

Internet Zone:
Internal URL: https://share.MyBusiness.com
Public URL: https://share.MyBusiness.com

14. Browse to one of your site collections from a machine on your network using your internal URL E.g. http://sharepoint/site1/home. You should be able to access it without any log in prompts and search etc. should be working.
15. Hop on an external machine and browse to your external URL. E.g. https://share.MyBusiness.com/site1/home. You should be presented with a log in dialogue. Enter your credentials and you should be in. Check that the site is secured with SSL (the little padlock should be showing) and that the search feature is working etc.

thats it (well - thats all I know so far...).

Please note that I haven't tested this much beyond this so there may be things that I have wrong yet which I haven't found. No doubt if anyone else reads this they will spot something.

 

If anyone has any more information about this problem just let me know!

Technorati tags: Support, MOSS, IIS, Search