I’m now signed up for feedburner so you can subscribe to my blog feeds – http://feeds2.feedburner.com/AlexsSharepointBlog.
I’m going to add a widget to the page that you can click too…
I’m now signed up for feedburner so you can subscribe to my blog feeds – http://feeds2.feedburner.com/AlexsSharepointBlog.
I’m going to add a widget to the page that you can click too…
I thought I should post a link to Spencer Harbar’s brilliant registry hack to allow you to right click any .wsp to add the solution to SharePoint – no more command line stsadm required!
Copy the registry text contained on his blog post here into a .REG file and execute – http://www.harbar.net/archive/2007/04/25/Rightclick-a-.WSP-to-Add-Solution.aspx
You can now just right click the .wsp and your away, personally I think this is one of the easiest methods and saves a lot of time.
It turns out the above error has been affecting a few people after upgrading to SP1 of MOSS/WSS, it can be fixed by restarting a few of the SharePoint/WSS services (see below) however the problem does come back after a while which can be irritating if you need to see the logs for a specific period.
I cannot see anywhere that this bug/issue has been reported to Microsoft so I’ll probably register it on the connect site if I can, I will post back here with the link – if you have the same problem could you put a comment on the connect site too please then we can get this issue noticed at MS.
EDIT: I have raised the issue as feedback on the MS Connect site, see here – https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=408671&SiteID=428 please leave a comment if you have the same problem.
To fix the error and start the logging again, simply restart the ‘Windows SharePoint Services Tracing’ service. Once this has been restarted you will notice the logs start again!
Maybe I will write a script to detect when it stops logging and restart the service…ill keep you all posted!
Cheers
If you use a featurereciever to install your event handler when you activate or install your feature then you can also uninstall/remove the event handler from the list/lists when the feature is either uninstalled or deactivated.
The code for removing the event handler is slightly more complex than adding the event handler and involves looping through the event receivers on the list and removing the one that matches the assembly name which you pass in.
Code:
//Open the parent site and web
using (SPSite site = (SPSite)properties.Feature.Parent)
{
using (SPWeb web = site.OpenWeb())
{
//Grab the required lists
SPList TheList = web.Lists["Shared Documents"];
//Declare the full assembly name
String AssemblyName = “SharedDocumentsHandler, Version=1.0.0.0, Culture=neutral, PublicKeyToken=928f76143tc8cbd2″;
//Create a new integer
int i;
//Use the above integer to loop through the event recievers on the first list and delete the above assembly
for (i = 0; i < TheList.EventReceivers.Count; i++)
{
if (TheList.EventReceivers[i].Assembly.Equals(AssemblyName))
TheList.EventReceivers[i].Delete();
}
//Update the list
TheList.Update();
//Update the SharePoint web
web.Update();
}
}
You can do the above for the FeatureDeactivating or FeatureUninstalling methods
.
I’m rebuilding a server and reinstalling WSS this morning, so I thought I post up a list of prerequisites required for a WSS installation. This should be a pretty helpful reference/checklist for a first time WSS install:
1.Windows Server 2003/Server 2008 OS Installed
2.IIS with ASP.NET support installed through Add/Remove Windows Components
3.Net Framework 2.0 (http://www.microsoft.com/downloads/details.aspx?familyid=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en)
4.Net Framework 3.0 containing Windows Workflow Foundation (http://www.microsoft.com/downloads/details.aspx?familyid=10cc340b-f857-4a14-83f5-25634c3bf043&displaylang=en)
5.ASP.NET v2.0 should be set to ‘Allow’ in the list of IIS web server extensions
6.SQL Server 2005 installed and configured (If you do not wish to use SQL Express which comes with the WSS install by default)
And your ready to go!
I needed to export a subsite this morning from a WSS Site Collection and import it to another Site Collection on another server. After a bit of rooting around, I found the stsadm commands to do just that.
If you wish to export a subsite or site collection (this will save a bak file containing the exported contents):
stsadm –o export –url http://server1:1000/subsite –filename c:\Subsite.bak
To import this exported site into another site collection/subsite, use the following command:
stsadm –o import –url http://server2:1001/subsite –filename c:\Subsaite.bak
In addition to the above you can add the following switches:
-includeusersecurity (ensures all the columns e.g. Modified by are maintained
-versions 4 (ensures all versions of list items/documents are exported
Note:
Make sure that the site you wish to import to shares the same template. E.g. if you are exporting a team site, you must import to another team site. If you try to import a site to a non matching template then you will get an error:
“The exported site is based on the template STS#1 but the destination site is based on the template STS#0”
I’ve just been working on a simple event handler to restrict users from deleting documents unless they are in a particular SharePoint group. This required me to access the SPWeb.Users function to iterate through the users.
If the user was not an administrator on the SharePoint site the code bombed out as the user doesn’t have permission to access the list of users on the site, this is happening because an event handler runs under the user who is performing the operation.
I decided to use the RunWithElevatedPriviliges to impersonate the Application Pool but this didn’t work either and as it turns out you cannot use ‘RunWithElevatedPriviliges’ in SharePoint event handlers!
In Trailblazer’s blog post –
he describes how you cannot use this method of impersonation nor the standard Windows.Impersonate() function in event handlers. The only workaround is to use Explicit Impersonation.
Explicit impersonation means creating an SPUser object for the administrator, getting the SPToken of the user and then using this token to open the SPSite.
See the code example below:
SPUser user = web.AllUsers["kci\\sp_prodapppool"];
SPUserToken token = user.UserToken;
SPSite kciSite = new SPSite(site.Url, token);
SPWeb kciWeb = kciSite.OpenWeb();
Have fun coding!
Dear all,
I have uploaded the ‘Generic’ version of my console application to sync Active Directory groups with SharePoint groups to Codeplex. This was a lot easier than asking people to request it on an individual basis. It is currently in beta, please visit the following url if you wish to download release 1.0:
http://www.codeplex.com/sharepointadsync
This afternoon I have noticed that a few of our WSS sites have stopped working, when trying to access them we got the following error:
HTTP/1.1 404 Connection: close Date: Tue, 26 Aug 2008 01:40:55 GMT Server: Microsoft-IIS/6.0 MicrosoftSharePointTeamServices: 12.0.0.6039 X-Powered-By: ASP.NET
It turns out this error is almost as common as the ‘Object Reference not set to an Instance of an object’ error. My research proved to be fruitless so I did some poking around on the server itself.
It turns out that this error can appear when a site collection has been created with no top level site.
e.g. http://yourserver:1000/sites/test
In the example above, a site collection has been created under ‘sites’ with no top level site, for the above to work correctly there would need to be a site collection here: http://yourserver:1000/
Sure enough the site in question had no top level site. Once I had created a blank one, the site was accessible again. I know for a fact that the site used to work so I am not sure that this error was introduced in a SharePoint/Windows update that has recently been released.
So keep your eye out
This is something which I feel is often ignored when creating SharePoint/WSS Sites for the first time. It is also something which is not very well documented. When creating a WSS or SharePoint environment either to replace an intranet or just a small collection of sites, it is important to design and plan the structure first.
Failure to do so can mean a large messy structure which is then difficult to reorganise, this is made even more difficult by the fact that SharePoint/WSS databases are not the easiest to work with.
The most important things to consider when planning are:
In addition to the above points, a ‘best practice’ document should be produced governing the creation of WSS/SharePoint sites. This will help to control and limit the creation of sites unless they are completely necessary.
When planning the site structure a tool like Visio is essential, if you are using Visio be sure to look at the Visio stencils for SharePoint:
Happy Planning (it will be worth it in the future!)