December 29, 2008 - 12:16, by Steven Van de Craen
Categories: Excel Services, Forms Server, Search Server 2008, SharePoint 2007, SharePoint Updates
This update really combines all previous updates so installation order is simplified.
- WSS SP1 (+ for all language packs)
- MOSS SP1 (+for all language packs)
- WSS December Update: x86 - x64 (separate downloads !)
- MOSS December Update: x86 - x64 (separate downloads !)
More info about that here: Announcing December Cumulative Update for Office SharePoint Server 2007 and Windows SharePoint Services 3.0
If you're extracting the MOSS December Update for 64 bit (368073_intl_x64_zip.exe) you might run into this error:
An error occurred while unzipping. One or more files were not succesfully unzipped. The error code is 110.
A workaround is to extract the archive using WinRAR (http://www.rarlabs.com/) and it will extract the files (you still need the password from the email of course).
December 19, 2008 - 16:36, by Steven Van de Craen
Categories: .NET, Search Server 2008, SharePoint 2007
The title of this blog post is referring to this screen in the List Settings:
It interests me because it
- allows you to control ownership of the item
- is only available to Lists but not to Document Libraries
- doesn't use unique permissions but some other mechanism
One thing it mentions is that it only works for users without Manage Lists permission on the list. So even if I manage to unravel its' secrets it isn't a waterproof solution (compared to unique item permissions for example). Still, if SharePoint has the notion of ownership it is definitely worth a closer look ! Maybe there's an opportunity here ?
It definitely isn't security by obscurity; if I navigate directly to an item that's not mine I still can't access it.
Peeking under the hood reveals that this setting is stored in SPList.ReadSecurity and SPList.WriteSecurity. Those MSDN articles contain all the details so I'll try not to be repetitive
ReadSecurity
Possible values:
-
1 - All users have Read access to all items.
-
2 - Users have Read access only to items that they create.
WriteSecurity
Possible values:
-
1 — All users can modify all items.
-
2 — Users can modify only items that they create.
-
4 — Users cannot modify any list item.
What about Document Libraries ?
For a Document Library these properties always have a value of "1" meaning everyone has read and write access (provided their permission level is sufficient). Since there is no interface in the Library Settings they cannot be changed. However nothing is stopping me from writing a few lines of code to update the settings, is there ?
using (SPSite site = new SPSite("http://moss/demo1"))
{
using (SPWeb web = site.OpenWeb())
{
SPList list = web.Lists["Shared Documents"];
list.ReadSecurity = 2;
list.WriteSecurity = 2;
list.Update();
}
}
Guess what ? It worked fine in the standard SharePoint Views and queries but not for WebDAV (Explorer View, etc). Probably the reason they only use it on SharePoint Lists.
An opportunity ? Not really since it doesn't act as real security in all scenario's. At least my curiosity is satisfied.
December 15, 2008 - 16:08, by Steven Van de Craen
Categories: .NET, Search Server 2008, SharePoint 2007, Debugging, Event Receivers, MOSS 2007, WSS 3.0
Today I got into some code reviewing of an Item Event Receiver using Enterprise Library for data access. The problem occurred when registering the Event Receiver for a SharePoint List using the object model (SPList.EventReceivers.Add)
Exception has been thrown by the target of an invocation.
Here's a simplified view into the code:
public class MyEventReceiver: SPItemEventReceiver
{
MyDataAccess da = new MyDataAccess();
public override void ItemAdded(SPItemEventProperties properties)
{
...
}
}
public class MyDataAccess
{
public MyDataAccess()
{
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase("MyDB");
}
...
}
Apparently when the Event Receiver is registered it instantiates the MyDataAccess class which in turn calls the EntLib method in its constructor. This is what causes the exception.
A solution is to instantiate the MyDataAccess class in the methods rather than on event receiver initialisation:
public class MyEventReceiver: SPItemEventReceiver
{
public override void ItemAdded(SPItemEventProperties properties)
{
MyDataAccess da = new MyDataAccess();
...
}
}
December 11, 2008 - 13:29, by Steven Van de Craen
Categories: SharePoint 2007
I had a new Active Directory security group created a few days ago but it still wasn't showing up in the Audience management pages when I tried to create a rule User member of AD group.
After double checking my group settings I couldn't find anything out of the ordinary and my MOSS 2007 server had all the latest patches so I was clueless. Spending some more time researching this issue led me to a forum post suggesting to do a full profile import and try again. And guess what... After a few minutes the AD group popped up right there. Not ideal but I'll take it nonetheless !
Update
To make matters worse if you add a user to the AD group and recompile the Audience it won't be added unless the profile import ran before compilation. This proves how hard the Audience mechanism relies on the User Profiles. And since the Profile Import can only be scheduled to run once a day there's quite delay on Audience membership updating.
Note: Audience Compilation by default happens each 15 minutes.
Summary
- Add AD Group: requires Full Profile Import for use in Audience Rules
- Add user to AD Group: requires Incremental Profile Import and Audience Compilation for updated membership
- Remove user from AD Group: requires Full Profile Import and Audience Compilation for updated membership
December 9, 2008 - 09:41, by Steven Van de Craen
Categories: SharePoint 2007
Consider the following scenario:
A MOSS 2007 Portal where everyone has read permissions but some 'content owners' have elevated permissions on libraries and lists and want to save a list as template (.stp).
In this case they need to have elevated access to the List Template Catalog (http://sitecollurl/_catalogs/lt). Minimal permission level for a user to save a list to the List Template Catalog is: Manage Hierarchy
In a MOSS 2007 Portal (based on the Collaboration Portal or Publishing Portal template) there is by default a SharePoint Group "Hierarchy Managers" created for this purpose. Alternative is to set list-level permissions on the List Template Catalog.