Site slowed down due graphical content

If your Sharepoint site had slowed down considerably since you added several images to it, that's all because IE was checking every image to see if it had changed before displaying it.

A quick change to the IIS Application can improve the performance of the Site by simply adding a cache-control directive to the response headers...

cache-control: max-age=3600, no-check

Another way to do it is to use the BlobCache which can be configured in the web.config. It also adds the max-age to the response headers:

#BlobCache location="D:\blobCache" path="\.(gifjpgpngcssjs)$" maxSize="1" max-age="3600" enabled="true" /#

Session state can only be used when enableSessionState is set to true

It's likely that some of us got this "Session state can only be used when enableSessionState is set to true..." Sharepoint Error while intending to extend a WSS HTTP site collection to HTTPS.

I have SSL enabled for my port 80 site but still get that message... what's wrong??

Well,

1- Make sure your WSS web site has been properly extended to SSL (this creates an https mirror site using another port). The content data is not replicated but shared among both sites (HTTP and HTTPS)

2a- Add enableSessionState="true" ... to the web.config file pages tag of the HTTPS site.

2b- Another option is just to copy/overwrite the HTTPS web.config file with the one at port 80 commonly located at \Inetpub\wwwroot\wss\VirtualDirectories\80

Still getting Access Denied when elevating rights?

In a previous post (elevated privileges) I explained how to access a SharePoint list when the actual user security is not enough.

You already did that and still get the same "Access Denied" message...?

When elevating rights we're using the SharePoint Web Site Application Pool user as the most privileged user the Web Application can use.

Look in your IIS logs and you should see a 401 somewhere. Yes?
That means that the user registered for the SharePoint web Site Application Pool doesn't have enough rights to access the list. In Simple deployments the common one is the Network Service account.

Now.., we need to change that and use a custom domain user as service account. Also it needs to be set as Service account in the server, or you'll get a "Service Unavailable" message in your browser when changing users.

To create a service account do as follows:

1- Create an account for the service in the domain i.e. DOMAIN\Svc_SharePoint
2- In the server excecute secpol.msc and head to Local Policies > User Rights Assignment > Log On as Service.
3- Add the DOMAIN\Svc_SharePoint service account
4- Add the DOMAIN\Svc_SharePoint service account to the IIS_WPG local group
5- Change the App Pool identity account to DOMAIN\Svc_SharePoint.
6- Recycle the App Pool (no need to reboot the server)

Be sure that the DOMAIN\Svc_SharePoint account has enough rights to access the List in the SharePoint collection and no more rights than that.

That should do the trick

Using ElevatedPrivileges in SharePoint Web Parts

Yesterday I found myself into a situation in which a custom web part couldn't reach a particular SharePoint list.

Situation:

Due to the current security schema, none user should have more than read access to the Root Collection Site and at the same time for centralizing purposes, a list was created on that Collection Site.
A particular web part located several levels down the collection needed access to that list, but as no common user had the appropiate permisison level it was returning the famous "Access Denied" screen.

Solution:

I needed to elevate the privileges on the web part at the time of accessing the list to solve the problem.

Guid RootSiteID = SPContext.Current.Site.ID;
Guid RootWebID = SPContext.Current.Site.RootWeb.ID;

SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite ElevatedsiteColl = new SPSite(RootSiteID))
{
using (SPWeb ElevatedSite = ElevatedsiteColl.OpenWeb(RootWebID))
{
rootList = ElevatedSite.Lists[_strSPListName];
}
}
});

Doing so, I could get the SPList rootList out of the site collection.

One important thing to remember is that you need to create a new SPSite and SPWeb within the RunWithElevatedPrivileges and not take them from the context in order to avoid using the current user "low privileges".

Adding the Recycle Bin to "Site Actions"

In a previous post I pointed on how to hide the recycle bin icon from the SharePoint site web page.

Now I'll create a merge between that and sending the Recycle Bin icon (with link) to the Site Actions drop down menu.
To achieve this I created a SP Feature called HideRecycleBin in order to have the chance to enable/dissable it depending on Sites/Subsites:

Feature.xml

---

Elements.xml

---

HideRecycleBin.css

---

HideRecycleBinReceiver.cs

---

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Diagnostics;
using System.IO;

namespace CustomFeatures.HideRecycleBin
{
class HideRecycleBinReceiver : SPFeatureReceiver
{
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
try
{
SPWeb web = (SPWeb)properties.Feature.Parent;
SPFile coreFile = web.Folders["Shared Resources"].Files["custom.css"];
coreFile.CopyTo("Shared Resources/customCSS-archive-HideRecycleBin.css", false);

SPFile customFile = web.Folders["Shared Resources"].Files["HideRecycleBin.css"];
customFile.CopyTo("Shared Resources/custom.css", true);
}
catch (SPException x)
{
logMessage(x.Message, EventLogEntryType.Error);
}
catch (Exception x)
{
logMessage(x.Message, EventLogEntryType.Error);
}
}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
try
{
SPWeb web = (SPWeb)properties.Feature.Parent;
SPFile customFile = web.Folders["Shared Resources"].Files["customCSS-archive-HideRecycleBin.css"];
customFile.CopyTo("Shared Resources/custom.css", true);

SPFile HideRecycleFile = web.Folders["Shared Resources"].Files["HideRecycleBin.css"];
customFile.Delete();
HideRecycleFile.Delete();
}
catch (SPException x)
{
logMessage(x.Message, EventLogEntryType.Error);
}
catch (Exception x)
{
logMessage(x.Message, EventLogEntryType.Error);
}
}

public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{
logMessage("View Hide Recycle Bin Site Action feature installed", EventLogEntryType.SuccessAudit);
}

public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
{
logMessage("View Hide Recycle Bin Site Action uninstalling", EventLogEntryType.Information);
}

private void logMessage(string message, EventLogEntryType type)
{
if (!EventLog.SourceExists("SharePoint"))
EventLog.CreateEventSource("SharePoint", "Application");
EventLog.WriteEntry("SharePoint", message, type);
}
}
}

Manifest.xml

---

Hidding the Recycle Bin in SharePoint

Working on customizing SharePoint lately? Needed to remove the recycle bin?

You just need to copy this code snippet into the .css that the web page is using:

#ctl00_PlaceHolderLeftNavBar_idNavLinkRecycleBin
{
Visibility:hidden;
}

and voilá, the recycle bin is not there anymore.

In a next post I'll explain how to create the Recycle Bin link in the "Site Actions" drop down list.

Assign Work Item to multiple TFS Users part. II

At this point we have customized the work item to allow asignments to

To view tasks assigned to SXD_Group you need to update the "View Query" for your Work Items.

1- Right Click "My Work Items"

2- Select "View Query"

3- Add a new clause: "Or" - "Assigned To" - "=" - "SXD_Group"

4- Close and Save

enjoy !

Assign Work Item to multiple TFS Users part. I

It is possible to assign an existent work item to multiple TFS users.

In this case I'm going to explain how to assign an existent work item to multiple TFS users but keep in mind that you can also create a new work item from scratch to accomplish this.

For this example we're going to use the following variables:

TFSServer: http://tfsserver:8080/
ProjectName: ProjectMX
WorkItem: task (to customize)

How to do it:

1- Create a i.e. MX_Group within the TFS project.
2- Add users to MX_Group group
3- Customize the task Work Item:

- Using the VS 2005 Command Prompt export the task Work Item :
witexport /f OutputXMLDef /t TFSServer /p ProjectName /n WorkItem

witexport /f "D:\Temp\Task.xml" /t "http://tfsserver:8080/" /p "ProjectMX" /n task

- Change the following in the exported Work Item definition:
















- Save the definition and import it back into TFS :
witimport /f XMLDef /t TFSServer /p ProjectName

witimport /f "D:\Temp\Task.xml" /t "http://tfsserver:8080/" /p "ProjectMX"

4- After restarting Visual Studio 2005 you should be able to assign tasks to MX_Group.

Cannot create TFS Project Sharepoint Site after WSS 3.0 Upgrade

In my Test Environment, after upgrading to TFS 2008 and WSS 2.0 to WSS 3.0 an issue raised.
No team project could be created. I was pretty sure that the problem resided in the TFS - WSS mappings.

WSS 3.0 upgrade gets configured by default using the TFS server name (NETBIOS name MyTestTFS in my case). Many test environments use the NETBIOS name and this is something to take into account if you plan to move it into production in some point.

Here's the deal. I first created the complete update command for Sharepoint knowing that just the Admin site needs to be changed…but just in case:

TFSAdminUtil configureconnections /SharepointURI:http://MyTestTFS.csystems.com.ar:80 /SharepointSitesUri:http://MyTestTFS.csystems.com.ar:80/sites /SharepointAdminUri:http://MyTestTFS.csystems.com.ar:17013 /SharepointUnc:\\MyTestTFS.csystems.com.ar\sites

Nothing fixed at this point and now unable to create the Project Sharepoint site when creating the Team Project. A different error raised.
So I went to the WSS Local Administration site and checked the mapped sites to find that http://mytesttfs.csystems.com.ar/ was not there. So I added it as alternate internal URL.

EVERYTHING WORKS ! Now TFS and Sharepoint are correctly mapped allowing Team Projects creation using the TFS Server frinendly name.