Improvements in SharePoint 2010 Service Pack1
As some of you already started testing the release of SharePoint 2010 Service pack1 and there is already enough fuss about this Service pack 1. Personally I feel that the SP1 release and the June CU for SharePoint 2010 releases added more fuel to the problem.
I have stressed this enough to install the Service pack 1 and then install the June CU.
Please see the link below for more detailed info on the improvements and various blogs posts by SharePoint MVP's.
Accessing the term store as a manager or contributor
Accessing the term store as a manager or contributor
Today 03/03, we ran into a situation where one of the users who manage the SharePoint 2010 Site was unable to access the term store management links.
I've touched on the term store a few times in posts this year. But as ever the best way to learn a new tool is to get a bit of practical experience. So I came across this little nugget this week when onsite with a client. Firstly a bit of background on the term store.
The building blocks of the term store are:
- Metadata application: Top level container of our term store. Contains groups
- Groups: Term sets are collected together in groups
- Term set: A hierarchical group of related terms
- Term: The basic building block of the term store. A metadata word
The term store can be managed by the following three groups of people:
- Term store administrator: Full control over the term store, and able to assign other people roles.
- Group managers: This role allows a user to manage a particular group of term sets
- Contributers: This role allows users to manage terms sets in a particular group, but they are not able to create additional contributers.
Term sets also have 'owner' and 'stakeholders' properties but these aren't actually used for anything.
Anyway the reason for this was post was to talk about how the roles described above access the term store. If the user has sufficient permissions to see 'site settings in 'site actions' then there isn't really an issue. They can navigate to site settings, and into the term store. However if the user cannot see the 'site actions' button their is no easy way to navigate to the term store at all. In fact it seems the only way is to link directly to it (and make sure you link to the term stored access via 'site setting's not central administration) and either distribute the link or post it somewhere. Whilst we have always had different permissions models outside of the standard user access model, this feels a bit different and all a bit unfinished. Have a look and see what you think. Comments below please.
Catch 22 for Approval Workflow in SharePoint Designer
Today 02/09 I began blogging on this, and found someone else's blogpost from Dec 2010 who also blogged on this exact topic. Though I never saw his blog post prior to writing this, credit to Lars Nielson.
I ran into an interesting dilemma while working on my most recent project. The project involved a number of document libraries that required content approval as well as versioning.
The scope of work greatly limited the amount of customizations that could be made to SharePoint (i.e. building workflows in Visual Studio).
This introduced an interesting problem based on our initial game plan. The workflow is basically a document goes through a change process and committee approvals before it is published. End Users cannot see changes until an approved document is published.
The change process was the complicated piece to this because the organization had a number of variables within the process, so the only solution was to require each step in the workflow to be manually kicked off.
When I made it to the approval stage, we initially had content approval on in the libraries. And here is where the catch 22 comes in, trying to set content approval status to Approved in a document library that requires a document to be checked out and content approval is on.
To set the content approval status from Designer, ok easy enough, there is an action for that....uh oh, the document must first be checked out. ok, check out document, set approval status....uh oh, I get an error that says content approval status cannot be set while a document is checked out.
Catch 22. Basically to set content approval status in designer, the document must be checked out, but content approval status cannot be changed while a document is checked out.
Possible work-around - We did not go this route, we basically turned off content approval, and used a workflow to notify approvals, and once approval was granted, a user would publish a major version of the document. This was acceptable for this engagement.
I was going to explain the workaround here, but I ran across a blog post while getting my info together of someone who already documented it. So in the spirit of giving credit where credit is due, Lars gets credit for this solution. Lars Nielson blogged on this exact topic in late 2010. http://discoverlars.wordpress.com/2010/12/28/update-the-approval-status-in-a-sharepoint-designer-workflow/
The bottom line in this is that for highly complex workflows, you really need Visual Studio.
How to Install a software update for SharePoint Foundation 2010
Recently we encountered some issues with the SharePoint updates. Even though the previous update procedures may be quite successful you may somehow find new or additional issues after the updates. Please see the below link from Technet explains the procedures for various SharePoint Server 2010 updates.
Click Here to see the Procedure for Updates
SharePoint 2010 boundaries, Thresholds and Supported limits
SharePoint 2010 boundaries, Thresholds and Supported limits
Many would be considering SharePoint 2010 for their environment and questions will be asked to SharePoint Admins and Architects on the product.
Here is some handy information from Microsoft on the limitations (boundaries) of SharePoint 2010.
Before we dive into it, letz define what are the limit types:
- Boundaries: Static limits that cannot be exceeded by design
- Thresholds: Configurable limits that can be exceeded to accommodate specific requirements
- Supported limits: Configurable limits that have been set by default to a tested value.
Best Practices in Developing Requirements for SharePoint Projects
This is one of my favorites blog posts from SharePoint Project Management Guru-Dux Raymond Sy.
I had the great opportunity to facilitate "Best Practices in Developing Requirements for SharePoint Projects" webcast for O'Reilly Media last July 28, 2010.
You can download the PPT presentation at: http://bit.ly/d1xbLN
Click the image below to watch the recorded presentation:
As promised, you can download the templates I showed at: http://www.meetdux.com/dl/req4sp.zip
In addition, I have compiled a list of valuable SharePoint resources related to the webcast:
- PM Resources for SharePoint 2010 Projects
- How SharePoint Can Deliver Project Transparency
- 5 Reasons Why SharePoint Ignorance is not Bliss
- Are you doing what it takes to Success at Implementing SharePoint?
- SharePoint Worst Practices: 5 Common Mistakes to Avoid
Lastly, if you want to join this session live, make sure you attend Best Practices Conference in DC from Aug 24-27, 2010
Plan SharePoint Server disaster recovery (DR Plan)
When creating a disaster recovery (DR) plan, you need to determine what you are trying to recover from. In other words, think of your disaster recovery plan as "taking out insurance" for your SharePoint environment. There are various levels of protection you might wish to set in place. You may be using a DR plan to create a replica of your portal to recover specific content, or you may wish to develop a plan to create a new environment from scratch (in the event of an actual disaster) that will quickly and effectively replicate the current environment.
For example, on one end of the spectrum, you could make things easy on your operational team and back up your data once every six months or so, but then you run the risk of losing a lot of data if something were to happen (a hard drive crashes, you lose power, and so on). On the other end of the spectrum, you can do a full backup of everything daily to ensure that you always have the latest of everything—but does that make sense for your environment?
To properly capture these types of decisions, we recommend creating a DR operations document.
The following is a framework for a SharePoint disaster recovery document. It is important to note that a DR plan is only effective if it is both complete and accurate.
An effective SharePoint DR plan should contain full documentation on how to recreate an entire SharePoint environment from scratch. This requires a process (and discipline) that is accurate and well-maintained. Every time a SharePoint element (for example, a Web part, xml file, and so on) is altered or added, the "disaster recovery inventory document" must be updated.