In the MOSS sites that have annonymous access and anonymous users, opening of an office document in a document library always requires entering username and password. If you cancel the prompt, the document still opens, but the prompt is annonying.
To prevent this prompt, change the linking to the document. That is, hyperlink to /sub1/Docs/mydocument.doc (where sub1 is the subsite, and Docs is the document library), should be changed as following:
/_layouts/download.aspx?SourceUrl=/sub1/Docs/mydocument.doc
Changing hyperlink to the reference would result into a simple download prompt of the document.
For more reference, visit the following post:
http://webborg.blogspot.com/2007/12/how-to-open-office-document-in-document.html
Thursday, July 16, 2009
Email notifications for alerts not being sent
I once faced an issue with email notifications for alerts on list/library not being sent.
The cause of the problem could be one of the two cases: Either the server has been upgraded from WSS 2.0 to WSS 3.0 or insufficient rights are given to the person/group for which alert is being set to. This is apparently a bug as suggested by Microsoft in the following article:
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B936759
My case was permissions related. We managed to solve the problem by going through the following steps:
1. Executed a couple of stsadm commands to enable the alert and set the time of the alert job
stsadm.exe -o setproperty -propertyname alerts-enabled -propertyvalue true -url http://problemsiteURL
stsadm.exe -o setproperty -propertyname job-immediate-alerts -propertyvalue "every 5 minutes" -url http://problemsiteURL
2. Reset Windows Timer Services.
3. Set the person/group for whom alert is being set to contribute permissions to the list/library for which alert is to be set.
In other cases, even after following the above steps if emails do not start, it might be due to upgrade, and difference of site urls in content database and actual web application. For this one of the two steps given in the MS article above needs to be taken.
The cause of the problem could be one of the two cases: Either the server has been upgraded from WSS 2.0 to WSS 3.0 or insufficient rights are given to the person/group for which alert is being set to. This is apparently a bug as suggested by Microsoft in the following article:
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B936759
My case was permissions related. We managed to solve the problem by going through the following steps:
1. Executed a couple of stsadm commands to enable the alert and set the time of the alert job
stsadm.exe -o setproperty -propertyname alerts-enabled -propertyvalue true -url http://problemsiteURL
stsadm.exe -o setproperty -propertyname job-immediate-alerts -propertyvalue "every 5 minutes" -url http://problemsiteURL
2. Reset Windows Timer Services.
3. Set the person/group for whom alert is being set to contribute permissions to the list/library for which alert is to be set.
In other cases, even after following the above steps if emails do not start, it might be due to upgrade, and difference of site urls in content database and actual web application. For this one of the two steps given in the MS article above needs to be taken.
Sending mails from a Sharepoint Development machine
On my virtual server, there is no SMTP server, so I always faced problems while checking mails sent by my workflows or setting alerts and checking them. One of my colleague came up with an email tool that lets you configure the outgoing email setting for your server, and then let you see the mail. But still it isn't so helpful, as I want to receive the mails, see the formatting, check on the links, etc.
For this came across the following tool:
http://www.toolheap.com/test-mail-server-tool/
It stores all the given emails at the specified location, Once installed, run it, it will start in taskbar, their are certain options which can be modified. Upon installation it comes with a user manual which is helpful, but there isn't much settings to do really.
Do not forget to set the outgoing mail settings as the name of your development machine..
Happy Sharepointing..
For this came across the following tool:
http://www.toolheap.com/test-mail-server-tool/
It stores all the given emails at the specified location, Once installed, run it, it will start in taskbar, their are certain options which can be modified. Upon installation it comes with a user manual which is helpful, but there isn't much settings to do really.
Do not forget to set the outgoing mail settings as the name of your development machine..
Happy Sharepointing..
Search not working on a MOSS site, "Access denied" error on search crawl
I faced this problem once, the search on my MOSS site did not seem to capture the latest documents or items. One look at the server and I found that crawl job is failing. Gives "Access Denied" error on search crawl. I obviously started by checking that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)"
I looked left right top bottom everywhere to get a plausible solution why it could break so suddenly. It was using the admin account as default content access, even tried changing that, to no avail.
Then came across the following solution after lots of digging on net, and a solution that is totally irrelevant to the problem, but neverthless tried it, and lo it works!!!
Solution is to disable the loopback check on the server. Use the following steps to do this:
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.
Anybody would wonder how the loopback check has to do something with the authentication on the moss server. So a possible explanation is given by the following article:
http://support.microsoft.com/kb/896861
In a nutshell they try to say that this issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
It sounds a bit relevant finally!! Hope it helps somebody facing a similar problem....
Happy Sharepointing!!!
I looked left right top bottom everywhere to get a plausible solution why it could break so suddenly. It was using the admin account as default content access, even tried changing that, to no avail.
Then came across the following solution after lots of digging on net, and a solution that is totally irrelevant to the problem, but neverthless tried it, and lo it works!!!
Solution is to disable the loopback check on the server. Use the following steps to do this:
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.
Anybody would wonder how the loopback check has to do something with the authentication on the moss server. So a possible explanation is given by the following article:
http://support.microsoft.com/kb/896861
In a nutshell they try to say that this issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
It sounds a bit relevant finally!! Hope it helps somebody facing a similar problem....
Happy Sharepointing!!!
Tuesday, May 26, 2009
Starting workflow programmtically from custom actions for users with readonly permissions
Recently was working with picture libraries, and had a scenario in which I was to start a workflow through a custom action. Additionally, the workflow should be started by all those users as well which do not have edit rights on the library for which workflow is started. So once have done it successfully, thought to post it up here.
First the Custom action part:
My custom action should appear on the ECB menu and edit toolbar of item in the library. For this I first create a feature.xml file which appears as:
<feature id="" title="Picture library Custom Action" xmlns="http://schemas.microsoft.com/sharepoint/" scope="Web">
<elementmanifests>
<elementmanifest location="UICustomActions.xml">
</elementmanifests></feature>
The scope of the above feature is web since, the custom action cannot be activated on site collection or web application level. Id would be a GUID generated through the CreateGUID tool.
The code for element file UICustomActions.xml is as follows:
<elements xmlns="http://schemas.microsoft.com/sharepoint/">
<customaction id="PicturelibraryFeature.StartWorkflow" title="Start Workflow" location="EditControlBlock" registrationtype="ContentType" registrationid="0x0101020047370705EAAA49c0B6E294964FE2D049" sequence="106" imageurl="~site/_layouts/images/imageAction.png">
<urlaction url="~site/_layouts/CustomPictureLib/WorkflowStart.aspx?List={ListId}&ItemId={ItemId}">
</customaction>
<customaction id=" PicturelibraryFeature.StartWorkflow" title="Start Workflow" location="EditFormToolbar" registrationtype="ContentType" registrationid="0x0101020047370705EAAA49c0B6E294964FE2D049" sequence="106" imageurl="~site/_layouts/images/imageAction.png">
<urlaction url="~site/_layouts/ CustomPictureLib/WorkflowStart.aspx?List={ListId}&ItemId={ItemId}">
</customaction></elements>
Above are two sections of Custom actions, one is for the ECB menu and another is for Edit tool bar. The attributes in the Custom action are clear by themselves. My aspx page is located in _layouts folder of the webserver.
To deploy these features, I create a folder at the following location C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES called “PicturelibraryFeature” and place both the xml files in it. Next comes installing and activating the feature through STSADM commands:
stsadm -o installfeature -filename PicturelibraryFeature \Feature.xml
stsadm -o activatefeature -filename PicturelibraryFeature \Feature.xml -url http://URL
The activation can be done through UI too.
Now the aspx page that is target url for our custom action, I call it WorkflowStart.aspx, it will be placed in a folder “CustomPictureLib” at the following location C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS of your web server.
This aspx page is a site page, so I include it in my project and also include a class file WorkflowStart.cs as its code behind.
The following is code for WorkflowStart.aspx:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WorkflowStart.cs" Inherits="CustomPictureLibrary.WorkflowStart, DIAPhotolibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4a78f6d69c6311d0" %>
<%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register TagPrefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<?xml:namespace prefix = asp /><asp:content runat="server" contentplaceholderid="PlaceHolderMain">
<h3>Confirm Workflow Start</h3>
<table>
<tbody><tr>
<td><asp:button id="btnConfirmRequest" onclick="btnConfirmRequest_Click" runat="server" text="Confirm Request"></td>
<td><asp:button id="btnCancelRequest" onclick="btnCancelRequest_Click" runat="server" text="Cancel Request"></td>
</tr>
</tbody></table>
<asp:label id="lblError" style="COLOR: red" runat="server" visibile="false"></asp:label>
</asp:content>
I include the code to start the workflow in the click event of Confirm button, the reason being workflow can be only called in postback. So to generate a post back, I place the code in there.
Workflow can be started through the following code:
using (SPWeb DIAWeb = DIASite.OpenWeb())
{
btnConfirmRequest.Enabled = false;
SPWorkflowManager objWorkflowManager = null;
SPWorkflowAssociation objWorkflowAssociation = null;
SPList pictureLib =
DIAWeb.Lists[new Guid(Request["List"])];
SPListItem pictureItem = pictureLib.GetItemById(Convert.ToInt32(Request["ItemId"]));
Guid approvalWorkflowId = new Guid();
pictureLib.WorkflowAssociations.GetAssociationByBaseID(approvalWorkflowId);
objWorkflowManager = pictureItem.Web.Site.WorkflowManager;
DIAWeb.AllowUnsafeUpdates = true;
objWorkflowManager.StartWorkflow(photoItem, objWorkflowAssociation, "");
DIAWeb.AllowUnsafeUpdates = false;
}
I execute the entire code to start the workflow in SPSecurity.RunWithElevatedPrivileges because this workflow can be started for those users too which have readonly access to my picture library. But this does not resolve my problem, still I was getting error as
“Attempted to perform an unauthorized operation”
This error I do not get when accessing the site as a system account or a contributor to this library. So how do I find a workaround this problem. To resolve this, I took help of the SharePointPermissionAttribute class, it has two members Unrestricted and Impersonate, am setting both to true on my class
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Unrestricted=true)]
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Impersonate=true)]
But guess what, I still get the same error. I read somewhere that the RunWithElevatedPrivileges is helpful when all the SP objects are declared and disposed within it. Also the site object should not be created using the current httpcontext object. So I made these few changes, and my complete code listing is as follows:
using System;
using System.Configuration;
using System.Web;
using System.Web.Security;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Security;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.Workflow;
namespace CustomPictureLibrary
{
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Unrestricted=true)]
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Impersonate=true)]
public partial class WorkflowStart : System.Web.UI.Page
{
protected Label lblError;
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
string mURL = SPControl.GetContextWeb(Context).MasterUrl;
this.MasterPageFile = mURL;
}
protected void Page_Load(object sender, EventArgs e)
{
lblError.Visible = false;
}
protected void btnConfirmRequest_Click(object sender, EventArgs e)
{
try
{
//Dynamically start the workflow
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite DIASite = new SPSite(this.Page.Request.Url.ToString()))
{
using (SPWeb DIAWeb = DIASite.OpenWeb())
{
btnConfirmRequest.Enabled = false;
SPWorkflowManager objWorkflowManager = null;
SPWorkflowAssociation objWorkflowAssociation = null;
SPList pictureLib =
DIAWeb.Lists[new Guid(Request["List"])];
SPListItem pictureItem = pictureLib.GetItemById(Convert.ToInt32(Request["ItemId"]));
Guid approvalWorkflowId =
new Guid();
objWorkflowAssociation = pictureLib.WorkflowAssociations.GetAssociationByBaseID(approvalWorkflowId);
objWorkflowManager = pictureItem.Web.Site.WorkflowManager;
DIAWeb.AllowUnsafeUpdates = true;
objWorkflowManager.StartWorkflow(photoItem, objWorkflowAssociation, "");
DIAWeb.AllowUnsafeUpdates = false;
SPUtility.Redirect(pictureLib.RootFolder.ServerRelativeUrl, SPRedirectFlags.UseSource, HttpContext.Current);
}
}
});
}
catch (Exception ex)
{
lblError.Text = ex.Message;
lblError.Visible = true;
}
}
}
}
Finally strong name the dll, compile it and place it in GAC. Also place the aspx form in the layouts folder, do an IIS reset and you are done!!
Hope it helps somebody and not take more days to workaround the errors I was receiving.
First the Custom action part:
My custom action should appear on the ECB menu and edit toolbar of item in the library. For this I first create a feature.xml file which appears as:
<feature id="" title="Picture library Custom Action" xmlns="http://schemas.microsoft.com/sharepoint/" scope="Web">
<elementmanifests>
<elementmanifest location="UICustomActions.xml">
</elementmanifests></feature>
The scope of the above feature is web since, the custom action cannot be activated on site collection or web application level. Id would be a GUID generated through the CreateGUID tool.
The code for element file UICustomActions.xml is as follows:
<elements xmlns="http://schemas.microsoft.com/sharepoint/">
<customaction id="PicturelibraryFeature.StartWorkflow" title="Start Workflow" location="EditControlBlock" registrationtype="ContentType" registrationid="0x0101020047370705EAAA49c0B6E294964FE2D049" sequence="106" imageurl="~site/_layouts/images/imageAction.png">
<urlaction url="~site/_layouts/CustomPictureLib/WorkflowStart.aspx?List={ListId}&ItemId={ItemId}">
</customaction>
<customaction id=" PicturelibraryFeature.StartWorkflow" title="Start Workflow" location="EditFormToolbar" registrationtype="ContentType" registrationid="0x0101020047370705EAAA49c0B6E294964FE2D049" sequence="106" imageurl="~site/_layouts/images/imageAction.png">
<urlaction url="~site/_layouts/ CustomPictureLib/WorkflowStart.aspx?List={ListId}&ItemId={ItemId}">
</customaction></elements>
Above are two sections of Custom actions, one is for the ECB menu and another is for Edit tool bar. The attributes in the Custom action are clear by themselves. My aspx page is located in _layouts folder of the webserver.
To deploy these features, I create a folder at the following location C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES called “PicturelibraryFeature” and place both the xml files in it. Next comes installing and activating the feature through STSADM commands:
stsadm -o installfeature -filename PicturelibraryFeature \Feature.xml
stsadm -o activatefeature -filename PicturelibraryFeature \Feature.xml -url http://URL
The activation can be done through UI too.
Now the aspx page that is target url for our custom action, I call it WorkflowStart.aspx, it will be placed in a folder “CustomPictureLib” at the following location C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS of your web server.
This aspx page is a site page, so I include it in my project and also include a class file WorkflowStart.cs as its code behind.
The following is code for WorkflowStart.aspx:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WorkflowStart.cs" Inherits="CustomPictureLibrary.WorkflowStart, DIAPhotolibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4a78f6d69c6311d0" %>
<%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register TagPrefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<?xml:namespace prefix = asp /><asp:content runat="server" contentplaceholderid="PlaceHolderMain">
<h3>Confirm Workflow Start</h3>
<table>
<tbody><tr>
<td><asp:button id="btnConfirmRequest" onclick="btnConfirmRequest_Click" runat="server" text="Confirm Request"></td>
<td><asp:button id="btnCancelRequest" onclick="btnCancelRequest_Click" runat="server" text="Cancel Request"></td>
</tr>
</tbody></table>
<asp:label id="lblError" style="COLOR: red" runat="server" visibile="false"></asp:label>
</asp:content>
I include the code to start the workflow in the click event of Confirm button, the reason being workflow can be only called in postback. So to generate a post back, I place the code in there.
Workflow can be started through the following code:
using (SPWeb DIAWeb = DIASite.OpenWeb())
{
btnConfirmRequest.Enabled = false;
SPWorkflowManager objWorkflowManager = null;
SPWorkflowAssociation objWorkflowAssociation = null;
SPList pictureLib =
DIAWeb.Lists[new Guid(Request["List"])];
SPListItem pictureItem = pictureLib.GetItemById(Convert.ToInt32(Request["ItemId"]));
Guid approvalWorkflowId = new Guid(
pictureLib.WorkflowAssociations.GetAssociationByBaseID(approvalWorkflowId);
objWorkflowManager = pictureItem.Web.Site.WorkflowManager;
DIAWeb.AllowUnsafeUpdates = true;
objWorkflowManager.StartWorkflow(photoItem, objWorkflowAssociation, "
DIAWeb.AllowUnsafeUpdates = false;
}
I execute the entire code to start the workflow in SPSecurity.RunWithElevatedPrivileges because this workflow can be started for those users too which have readonly access to my picture library. But this does not resolve my problem, still I was getting error as
“Attempted to perform an unauthorized operation”
This error I do not get when accessing the site as a system account or a contributor to this library. So how do I find a workaround this problem. To resolve this, I took help of the SharePointPermissionAttribute class, it has two members Unrestricted and Impersonate, am setting both to true on my class
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Unrestricted=true)]
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Impersonate=true)]
But guess what, I still get the same error. I read somewhere that the RunWithElevatedPrivileges is helpful when all the SP objects are declared and disposed within it. Also the site object should not be created using the current httpcontext object. So I made these few changes, and my complete code listing is as follows:
using System;
using System.Configuration;
using System.Web;
using System.Web.Security;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Security;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.Workflow;
namespace CustomPictureLibrary
{
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Unrestricted=true)]
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Impersonate=true)]
public partial class WorkflowStart : System.Web.UI.Page
{
protected Label lblError;
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
string mURL = SPControl.GetContextWeb(Context).MasterUrl;
this.MasterPageFile = mURL;
}
protected void Page_Load(object sender, EventArgs e)
{
lblError.Visible = false;
}
protected void btnConfirmRequest_Click(object sender, EventArgs e)
{
try
{
//Dynamically start the workflow
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite DIASite = new SPSite(this.Page.Request.Url.ToString()))
{
using (SPWeb DIAWeb = DIASite.OpenWeb())
{
btnConfirmRequest.Enabled = false;
SPWorkflowManager objWorkflowManager = null;
SPWorkflowAssociation objWorkflowAssociation = null;
SPList pictureLib =
DIAWeb.Lists[new Guid(Request["List"])];
SPListItem pictureItem = pictureLib.GetItemById(Convert.ToInt32(Request["ItemId"]));
Guid approvalWorkflowId =
new Guid(
objWorkflowAssociation = pictureLib.WorkflowAssociations.GetAssociationByBaseID(approvalWorkflowId);
objWorkflowManager = pictureItem.Web.Site.WorkflowManager;
DIAWeb.AllowUnsafeUpdates = true;
objWorkflowManager.StartWorkflow(photoItem, objWorkflowAssociation, "
DIAWeb.AllowUnsafeUpdates = false;
SPUtility.Redirect(pictureLib.RootFolder.ServerRelativeUrl, SPRedirectFlags.UseSource, HttpContext.Current);
}
}
});
}
catch (Exception ex)
{
lblError.Text = ex.Message;
lblError.Visible = true;
}
}
}
}
Finally strong name the dll, compile it and place it in GAC. Also place the aspx form in the layouts folder, do an IIS reset and you are done!!
Hope it helps somebody and not take more days to workaround the errors I was receiving.
Wednesday, February 25, 2009
Error with Publishing Infrastructure Feature
Recently I came across a scenario where the styling and branding of one of the sites, was not inherited by its site collections. Basically, the structure was like http://website/sites/site1. Also when I tried to explicitly go and change the master page and .css file in the site1 site collection, I could not see master page setting in Site settings.
Then a colleague told me that this is because publishing infrastructure option which is responsible for layout and content structure is not activated. So I tried to activate the feature on the site collection.
Well not so easy, I started getting the following error:
"Creation of folders is not allowed for this template"
I googled a lot, but could not find a solution, since most of the people get an error on activating this feature, but it is generally "Access Denied" one. So atlast not being able to come up with any solution, I tried to activate the feature through stsadm command:
stsadm -o activatefeature -PublishingResources -url http://website
But I faced error with this too, cannot create content kind of error. So the next option that I tried is use -force with the stsadm command.
And yes operation successful message was received. But still I cannot see the feature as activated in the site collection features list. However, the masterpage setting, and other folders did get created.
Now lets come to why possibly this error would be coming. I could come to the conclusion that this was happening because my application had been upgraded from SPS2003 to MOSS, and apparently migration did not happen correctly with this site collection.
Also if the -force option does not help, then the next idea is to reset the site definition. Through this you will lose your styling or layout changes which you might have done explicitly for this site, but atleast you can try out. Make sure you take appropriate backups before applying something drastic.
Happy Sharepointing.
Then a colleague told me that this is because publishing infrastructure option which is responsible for layout and content structure is not activated. So I tried to activate the feature on the site collection.
Well not so easy, I started getting the following error:
"Creation of folders is not allowed for this template"
I googled a lot, but could not find a solution, since most of the people get an error on activating this feature, but it is generally "Access Denied" one. So atlast not being able to come up with any solution, I tried to activate the feature through stsadm command:
stsadm -o activatefeature -PublishingResources -url http://website
But I faced error with this too, cannot create content kind of error. So the next option that I tried is use -force with the stsadm command.
And yes operation successful message was received. But still I cannot see the feature as activated in the site collection features list. However, the masterpage setting, and other folders did get created.
Now lets come to why possibly this error would be coming. I could come to the conclusion that this was happening because my application had been upgraded from SPS2003 to MOSS, and apparently migration did not happen correctly with this site collection.
Also if the -force option does not help, then the next idea is to reset the site definition. Through this you will lose your styling or layout changes which you might have done explicitly for this site, but atleast you can try out. Make sure you take appropriate backups before applying something drastic.
Happy Sharepointing.
Subscribe to:
Posts (Atom)
