Use SharePoint, but also like all the work that communities around WordPress, Drupal, and Joomla are doing? Guess what, there’s an answer. SharePress. I could write it up, but it’s already been one over at http://weblogs.asp.net/bsimser/archive/2010/04/01/introducing-sharepress.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+bsimser+%28Fear+and+Loathing%29 –
One of the most common questions I get asked from developers is “What is the best way to set up a SharePoint Dev Environment. And they normally get a much longer answer than they’d like – there are a lot of things that can affect the answer – how many people are working together, what are their roles, how locked down are your developer boxes, are you using TFS… the list goes on.
Well, things are changing for SharePoint 2010. And it’s a change for the better – I’ll cover a lot of the new items as we go along, but I would like to point out that the MSDN documentation now calls out the “standard” process for setting up a dev environment. You can find it at http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx and use it as a basis for putting together your own customized development environment.
If you want a little more discussion on the matter, you can see what’s going on in the SharePoint Dev Wiki at http://www.sharepointdevwiki.com/display/sp2010/Building+a+SharePoint+2010+Development+machine
As I look back at the history of SharePoint, one of the primary features that made it so popular is the ability to store and work with any type of files. This is GREAT from a user standpoint, but that capability requires that SharePoint work with those files as a BLOB (Black box of bits) when it stores them. Second order issue for that then becomes that differencing versions of files becomes impractical and thus you end up with a copy of each version of a file. If you’ve got a lot of active people working on documents, and you’re tracking versions – you end up having two basic options. Limit how many versions of those files you will keep (putting a limit on how useful versioning is in the first place – not something your users will like), or throw LOTS of database space at your implementation (something that could have your DBA coming after you with a brick.)
Well, with the 2007 generation of SharePoint, the product team introduced a feature deep in the technical documentation to allow remote blob stores. This was something they were working very hard on to get to the right level of performance, ease, and API maturity so they kept it a bit low key. But with the 2010 generation of SharePoint that we’re testing today, that capability is coming to the forefront for implementations that have very large numbers of files, or even organizations that already have mature file stores, and would like SharePoint to provide even easier integration.
If you’re in either of these situations, or just interested in catching up with something that’s been around for a bit, but hasn’t been really in the spotlight, I’d highly recommend taking a look at the capabilities.
I get asked a LOT for a short list of what has changed between SharePoint 2007 and SharePoint 2010. Unfortunately that list is never short as there are more factors to dive into than most people want to look at – at least in a short list. Level, configuration, licensing, User tools, it makes a pretty impressive matrix. But there is an MSDN article that helps out by providing a general overview of many of the SharePoint new features and capabilities.
Can help you plan what you want to learn more about and dig deeper into. It’s a very nice overview of some of the high points from a capabilities model. For a deeper dive into the development capabilities though, you’ll need to either check out the SharePoint conference material or tune in for the content that Zain is working up for our launch events in the spring.
You may remember the high priority post back in May (Important information on SharePoint Server 2007 based products and SP2) about an issue with the state of activation after SP2 is installed on SharePoint Server and associated servers. There was a pretty simple fix posted, but if you want to script the fix or just use the officially blessed correction to the issue, Hotfixes have been released for both the 64bit and 32bit versions of the SharePoint servers.
(Blogged for my reference and to close the loop on the follow up action with the release.)
If you have installed (or are in the planning stages of installing) SP2 on any of the SharePoint Server 2007 based products (this includes Form Server, Search Server, Project Server, etc) then you NEED to head over to the SharePoint Team Blog and take notice of an issue that has been found. The post on the issue is at
The short version is that the SP2 install has an issue with the activation date – this will not affect any data or settings, but can affect your SLA’s if you haven’t taken the action described in the article.
Find the details on the SharePoint Team Blog!