Tools for your SharePoint 2013 development toolbox

Check out these great articles that walk you through the new tools and techniques that every developer should have in their toolbox.


http://zimmergren.net/technical/tools-for-your-sharepoint-2013-development-toolbox

Automating SharePoint Development – Iterative Development Process

Check out these great articles that walk you through how to set up most of recent projects with routines for the daily iterative development work. This includes Continuous Integration, Nightly Builds, Automated SharePoint Deployments and Automated UITesting. 

http://zimmergren.net/business/automating-sharepoint-development-iterative-development-process

how I’ve set up most of my recent projects with routines for the daily iterative development work. This includes Continuous Integration, Nightly Builds, Automated SharePoint Deployments and Automated UITesting. Pretty slick. - See more at: http://zimmergren.net/business/automating-sharepoint-development-iterative-development-process#sthash.XiEdcSkr.dpuf

Best practices for installing, configuring SQL Server 2012 for Sharepoint 2013

Best Practices for SQL Server Database 2012 settings, check out these great articles that walk you through the installation process for SQL Server 2012 SP1, and in the companion articles,  explain the post-installation configuration changes should made to SharePoint 2013. As an added bonus, a 27-minute video walkthrough of the same SQL Server installation and configuration.

Set Up SQL Server 2012 as a SharePoint 2013 Database Server
http://sharepointpromag.com/sql-server-2012/sql-server-2012-sharepoint-2013-database-server-setup

Configure SQL Server 2012 for SharePoint 2013
http://sharepointpromag.com/sql-server-2012/configure-sql-server-2012-sharepoint-2013

Fine-Tune Your SQL Server 2012 Configuration for SharePoint 2013
http://sharepointpromag.com/sql-server-2012/fine-tune-your-sql-server-2012-configuration-sharepoint-2013

Top 25 Most Popular Project Management Blogs of 2013

Below is a list of the most popular top 25 project management blogs that have been visited from ProjectNewsToday.com over 2013:

1. Herding Cats
2. PMI Blog - Voices on Project Management
3. QuantmLeap
4. Arras People - How to Manage a Camel
5. A Girls Guide To Project Management
6. Virtual Project Consulting
7. Zilicus
8. The Tao of Project Management
9. ProjectManager.com
10. Ron Rosenhead
11. Leadership Freak
12. Mike Clayton
13. The Program Manager
14. Brad Egeland
15. Musings on Project Management
16. Leadership Thoughts
17. Gina Abudi
18. Sensible Project Manager
19. Better Projects
20. Software Project Management
21. Ahha Moments
22. Guerilla Project Management
23. Lazy Project Manager
24. Henny Portman
25. EarthPM

I highly recommend that you check these sites out and subscribe to their updates.

Case Study: SharePoint Governance Lessons Learned

Christy Punch, Senior Intranet Strategist at SCANA Corp and Share Conference speaker tells us about the lessons she learnt when implementing a governance plan in her organisation and shares her tips on what (and what not) to do.

Times are tight. You'll have to make do. We hear it all the time in business and unfortunately there are not many organisations or industries that are exempt from hearing these phrases.

When faced with tight budgets and limited resources, sorting out SharePoint governance can be a daunting task. Especially if you're largely managing it yourself. But SharePoint governance is an important piece of the puzzle to get right and resource strain should not be a reason to forget about it altogether.

The good news is that it can be done with limited resources and virtually no budget. With some careful planning and strategic positioning, you too can create a solid governance plan that everyone can get on board with.

Here are three lessons Christy Punch with SCANA Corporation shared with us that she learned from putting together a SharePoint governance plan at her organisation that may help you when thinking about your own plan.

Do your homework  

Christy found that the best approach for her organisation was to do a lot of the work ahead of time and keep it very simple.

Based on her experience of managing the intranet and working with different people across the organisation, she developed and documented processes, guidelines, training plans, security levels and roles- all the elements she knew her intranet stakeholders were going to be concerned about. Christy made sure this governance documentation was simple and succinct. For example, the SCANA Corp. intranet guidelines for what content belongs on the intranet is only eight bullets long.

Once you have all your governance elements together, you’re ready to talk to the business.

Don’t get everyone in the same room  

One mistake Christy thinks a lot of people make is pulling 10-20 people representing each area of the company together in a room to decide on a governance strategy. What happens here is there are too many cooks in the proverbial SharePoint kitchen. Most people don't know where to begin, in fact most people don't even understand what SharePoint governance is!

Christy instead created processes and documented everything ahead of time before meeting with stakeholders. Then she met with stakeholders individually and walked each through the governance plans and documentation. She explained what they had set up and what risk mitigation plans were in place to address the stakeholder’s unique concerns. Christy then had each stakeholder sign the document to say they had seen it and that they gave their approval to go ahead.

A key consideration here is to make sure to explain how each part of the governance plan acknowledges their concerns and issues. What Christy found was that most stakeholders were so impressed that the team went ahead and did the work upfront and were willing to own governance. It made the governance buy-in process go very smoothly.

Have a retention policy 

 Christy told us that if they could have done one thing differently, it would have been to build a retention policy into the governance plan from the beginning. For example, what do you do with content that is no longer relevant on your intranet, but you need a record of it? What happens to that PDF form that’s been updated? Does the older version need to be archived?

This is one thing Christy and her team at SCANA did not do when they created their initial governance, but something they are currently trying to get in place before the upgrade to SharePoint 2013 next year. The company has existing retention policies for email, personal drives, and shared drives, but the team didn’t consider creating a policy for the intranet. Christy admits that it is an easy need to overlook, because when you launch your new intranet with updated and new content, you don’t really think you’ll need a retention policy.

Even with audits in place to keep content up-to-date and to ensure governance is being followed, four years later we make retention decisions on a case-by-case basis. Content is only growing and we realize that a formal retention policy is needed more than ever.

Three Common Mistakes with SharePoint Governance

Most organisations understand that a good governance policy is essential for any SharePoint deployment. So they create a governance plan. Done. Unfortunately that’s not the way it works. SharePoint governance is a complicated beast and many-a-plan has failed to be implemented because of lack of communication, over complication or producing an epic document that no one reads.

Let us outline three common mistakes people make with governance plans and how we can avoid making them.

1. People don’t know why they should follow your governance policy What often happens with 

SharePoint governance plans is that they’re produced (usually a lengthy document), uploaded to SharePoint along with an email to staff saying it’s there and they should refer to it for any SharePoint related guidance. This method of communication is what I call "toss it over the fence and hope that someone catches it". Do this and it’s very unlikely that your SharePoint governance document is going to be read, let alone followed.

Fix it 

Once your SharePoint governance policy is finished, make sure you communicate why you want people to follow this. Simply stating that people should follow it is not going to cut it. Telling people that they have to follow these policies just because is not going to be as effective as telling them if you tag your document it will make it easier to find later on. Or by following this policy you are helping us avoid legal issues.

Think about your own governance policies and what positive effects will flow from following them. Are there some time consuming tasks that can be sped up by following correct SharePoint governance policy? Will complying with these policies improve business productivity? Will it help staff build better working relationships with their colleagues? Most people have a commitment to making the business work as well as to their colleagues but only if they understand why they are doing it.

2. You make it hard for people to be compliant 

Complying with a governance policy is important, especially when there are legal ramifications. For example, one of the bigger issues especially in the US is that if you have a governance policy and you're not following it, you have created a big litigation risk. So one of the real reasons to focus on governance is to avoid the risk of not meeting legal requirements or having to spend a lot of money in the eDiscovery process when you get sued.

But perhaps people don’t know about this risk (see number one above) or the process for complying contains so many steps and is so time consuming that people are not going to bother with it.

Fix it 


Automate as much as possible to take the hard work out of complying with your SharePoint governance policy. Use templates so that all sites start with good governance built right in. When possible, use a third-party tool to make it easier to ensure compliance.

3. Your SharePoint governance policy is a beast of a document 

We’re really good at writing 100+ page governance documents. Even if you believe it’s a masterpiece and you can think of nothing better than pouring a good glass of red and settling in for the night to read it, I don’t know many people who would agree. It’s a shame because your governance plan actually contains valuable information that people need to know.

Fix it 

No one reads long documents so don’t create a SharePoint governance plan as a long, boring document. Think about creating small bits of consumable information. Wiki pages and quick guides are a great way to easily great small, visually appealing consumable bits of governance guidance.

But if you really want to make it easy for people, deliver your governance content in the context of where people work. For the most part, people won’t pay much attention to governance (or training) until they need to know how to do something. Try to go for “just in time governance”: small chunks of SharePoint governance information delivered at the moment you need it.

For example, if I’m creating a document, I’m probably concentrating on writing the document, not thinking about what file naming convention I should use. I’m only worried about this when it comes to saving my document. So ideally you want your quick guide about file naming conventions to surface when I’m about to save it. Like magic!

A simple, “no code” way to do this is to use Content Editor Web Parts (CEWP) on document library pages. CEWPs allow you to surface information “in place” for this kind of thing.

Although SharePoint governance plans can be seen as just a necessity, the information in your plan is extremely valuable and can help make life easier, not harder, for your users. Make sure you’re communicating the value to your users, making it easy through automation tools and providing “just in time” governance and training.



 

Infrastructure Design Changes in SharePoint 2013

Great presentation from Michael Noel "Infrastructure Design Changes in SharePoint 2013" 

No Code SharePoint Strategy

We will not do anything that involves custom code. We will restrict ourselves to what we can do with out-of-the-box SharePoint and associated tools.

This is somewhat controversial. I can already hear rumblings of discontent from distant IT strategists. IT strategy should be derived from business strategy, right? An IT strategy should put in place systems and practices that support the business in achieving its objectives. If we say “we won’t do any custom code” this is surely a classic case of tail (technology) wagging dog (business). Why should the constraints of a technology be used to tell the business what they can and can’t have?

That is perfectly true. But, and it’s a big but, SharePoint also gives us the following to consider:

• The number of things that SharePoint can potentially do for a mid-size to large organisation is pretty large. It encompasses collaboration, intranet, document and content management, social features, search, business intelligence, and business application delivery. Deciding where to start can be a challenge.
• As soon as you start custom coding within SharePoint (or anything else), the cost and risk both go up considerably.
• For almost all organisations there are some real “quick wins” that can be delivered without custom code. For example, we often build one or two form and workflow driven business applications. These can be delivered in a matter of days and provide tangible value. The appropriate use of third party products such as those from K2 and Nintex can also facilitate the delivery of more complex workflows without custom code.
• Users and stakeholders want to see something. Custom coding projects can take months. A no code approach gives them rapid visibility of where all that money they spent on licencing has gone.

I should make it clear that I am not advocating that custom code should never be used. If for example you have a requirement with a compelling business case that can only be delivered with custom code, then make the case and go for it! However if you are looking at SharePoint, and have numerous possible projects under consideration, then an initial no code approach will allow you to derive some quick benefits at low cost and low risk.

You can then revisit your strategy later once users have got used to the system. At this point you’ll probably find that business requirements have changed anyway, as once people have started using and benefitting from SharePoint, their thoughts about where they need additional functionality almost inevitably change. So when you decide it is time to crack open Visual Studio and start custom coding, the chances are you’ll end up with a better custom coded solution than you would have had if you’d done the custom work up front.

Information Architecture

What information architecture (IA) is.  To be more precise, we need to explain a handful of topics around the subject:

1. What is information architecture?
2. Why is information architecture important?
3. What is information architecture, specific to SharePoint?
4. What is the difference between information architecture and information management (IM)?
5. When should information architecture be addressed?

I will attempt to answer these questions with two goals in mind:

• For those new to the concept of IA, provide an introduction to core concepts. 
• For the more initiated, provide a framework (a checklist?) or at least a starting point to make sure the main points are being addressed in their own projects.

This isn't meant to be fully inclusive but will, I hope, get readers thinking about their own requirements to make sure they've addressed all the areas they need to.

What is Information Architecture?

 

For an "official" definition a good place to start is provided by the Information Architecture Institute.  They describe IA as "the art and science of organizing and labeling websites, intranets, online communities and software to support usability."
I quite like this definition.  It truly is a little art and a little science.  But it's a tad narrow.
Another definition I'm fond of is one I've heard Randy Williams use, which is "your company’s way of describing, organizing and discovering your content."  This is a lot more high level, which I like as it leaves room to include all of the things that make sense in your project.
More specifically, IA tends to include the following aspects of a website:

• site taxonomy/structure
• metadata
• search schema
• navigation

These are all interrelated.  In fact in many cases, one drives or informs the other. For example, if you're employing navigation that is automatically driven by the site's structure, your site taxonomy will impact the usability of your navigation.
Further, though I won't focus on it in this blog, a key driver of your IA may be another topic of interest (and confusion): SharePoint governance.
As an example, imagine a company has created a governance plan, which states that SharePoint sites containing customer data must have auditing and content expiration policies applied to them.  Because these sites represent a small subset of the overall application, it may be wise to segregate them in their own site collection where the policies can be applied, while other sites can reside outside of this "special" site collection without the overhead of these policies.
For more on governance, I recommend reading A Definitive Guide To SharePoint Governance: Whitepaper by SharePoint MVP Jeremy Thake, Randy Williams, and Richard Harbridge. But for now, this should illustrate the point that governance may impact IA.

 

Why is Information Architecture Important?

 

This is a good question.  Why should you care about IA?  Is it just an abstract exercise or does it have an impact on your site's users?  The answer is that it is absolutely crucial, and in many ways.  To name a few:

1. Usability - Sites that lack a well-thought out IA tend to be less usable.  It's more difficult to find information and site navigation tends to be substandard or confusing.
2. Adherence to Governance Plan - As alluded to earlier, your IA may be one piece of how a governance plan is executed or adhered to.
3. Compliance - Policies that allow us to adhere to compliance regulations are quite often driven by metadata.  If the metadata design is lacking, it may be difficult or impossible to stay in compliance, which can have tremendous legal and financial repercussions.
4. Site Management/Administration - A strong IA will help prevent site sprawl and may help address storage requirements or goals.

Simply put, without an IA in place, your site will be inconsistently tagged, poorly organized, and difficult to use.  And depending on the criticality of your site, this could be either a small annoyance or have much more grave significance.

What is Information Architecture, Specific to SharePoint?

 

In general, SharePoint IA requires attention to the same topics that any other website does.  But SharePoint does warrant a specific discussion because there are SharePoint-specific mechanisms and structures that must be addressed and because SharePoint's nature is to empower users to create sites and content on their own.

If the IA is not well thought out (as well as executed and adhered to), site sprawl and other undesired results are sure to emerge.  Some of the SharePoint-specific topics that must be addressed are these:

Content containers - By this I mean, deciding whether content or sites will reside in a specific farm, web application, site collection, or subweb.  Decisions about where to provision a specific site will include, among other things, configuration requirements, compliance/data segregation/encryption, specific SLAs, and navigation.

Metadata Structure - This includes defining Managed Metadata term sets, site columns, content types, content type hubs, and more.

Search Schema - SharePoint Search managed properties and crawled properties (and their mappings) must be well thought out to ensure quality search results as well as setting the system up to create search-based applications.

Now, I mentioned this isn't a full list, but even so, you might have noticed there are some obvious things missing.  Which leads me to the next topic.

What is the Difference Between Information Architecture and Information Management?

 

At a high level, I think of IA as the design and planning of your application whereas IM is the implementation, application and execution of that design.

So as an example, your IA may define a metadata taxonomy for tagging content and a content type hub to manage those terms centrally.  The IM part of this would be, perhaps, configuring auto-tagging on this library to make sure that the tags are actually applied.

Another way to look at this is that IA describes where and how content is organized, while IM is an application of tools and configuration that describe how this information behaves.
Some of the areas of IM that need to be addressed follow:

Permissions/Security - Who has access to the content?  What different permission levels are available to apply?

Content Lifecycle - When does an item become a record?  When and how is old content archived?  Is content ever expunged from the site?

Policies - What type of auditing and reporting is required for the content?  Can the information be printed or emailed?

Provisioning Process - How are sites provisioned?  Which site templates are made available?  Where can sites be created?

Again, there's more to consider here, but this should get you thinking about the types of things to plan for and configure in your implementations.

When Should Information Architecture be Addressed?

 

There's an easy answer to this question.  You should address IA early and often.  If there's one thing to take away from this blog it is that last sentence.
IA should be planned for very early in the project.  In my opinion, it should follow the initial governance planning.  This is because the governance plan will in some way or another define then IA.

IA should be revisited often.  Requirements change over time, sites change over time.  Your SharePoint application is a living breathing thing and your IA (as well as many other aspects of your SharePoint solution) should be reviewed and updated on a frequent basis to make improvements and address the current needs of the business.

Wrap Up

I hope this has been a good intro or refresher on the basic tenets of SharePoint information architecture.  The key takeaways I hope you'll get are as follows:

1. IA describes where and how content is organized, while IM is an application of tools and configuration that describe how this information behaves.
2. IA should be addressed early and often.
3. IA and IM are two major components used to apply and execute your governance plan.
4. A strong information architecture will result in a highly usable site that adheres to compliance regulation, is easy to manage, and where it's easy to find data.

Refresh of SharePoint Server 2013 IT Pro training now available

I would like to announce a refreshed version of the technical training materials for Microsoft SharePoint Server 2013. This training package is for administrators, architects, and business analysts for learning all the new capabilities and functionalities in SharePoint Server 2013. Content doesn’t only concentrate on SharePoint configuration, but also covers the different new functionalities from user experience perspective.

This training package is publicly available from the SharePoint TechCenter and contains multiple videos and downloadable presentations that are used with the videos.

What was actually released?

The released package contains many technical details across the SharePoint Server 2013. This is the refreshed version of the previously released training package, and all materials have been updated to match the RTM version of SharePoint Server 2013.
All videos include slide shows, and most videos contain at least one demo that shows the covered concepts in detail.

• 51 presentations and videos
• Over 17 hours of video
• 790 PowerPoint slides about SharePoint Server 2013

The material has been separated into to 14 modules. Each one contains one or more videos lasting anywhere from 5 minutes to more than an hour.

• Introduction
• System Requirements
• Architectural Changes
• Farms and site architecture planning
• Office Web Apps 2013 architecture and deployment
• Service application architecture
• Enterprise Search
• Social Features
• Enterprise and Web Content Management
• Customization options and management
• Authentication and authorization
• Business Continuity Management
• Upgrading to SharePoint Server 2013
• Project 2013 for IT Professionals

 

Frequently asked questions

Here are a few frequently asked questions related to the refreshed package.

• Can I use these materials in my own presentations?
• Yes. These are made downloadable so that you can use these presentations for explaining the awesomeness of SharePoint Server 2013
• Is there a download option for the videos?
• Unfortunately, no. These videos are currently only available online. We are investigating how to make them available for offline download.
• Is there some additional information related on Project 2013?
• Yes. Check the new Project 2013 training for IT pros and developers training, which was also just released.

eDiscovery in SharePoint 2013

SharePoint sites will have large amount of data in documents, Social data, web pages and  email messages. We may have some legal risks with keeping the data and searching the data. In that scenario we can search and export it into usable format. In SharePoint, eDiscovery capabilities will help to achieve the requirement. eDiscovery requires searching for documents, sites, pages, emails from all the email servers, file servers and collect the data as per the format of legal case. We can simply define the eDiscovery as “the process of finding, preserving, analyzing and producing the content in electronic format as required format of investigators.”

 

Microsoft people introduced the Hold and eDiscovery feature in SharePoint 2010. In SharePoint 2013 added few capabilities to reduce the cost and complexity of the discovery. Following are the new features introduced in SharePoint 2013,

 

• eDiscovery center: it’s SharePoint site used to manage preservation, search and export the content stored in Exchange and SharePoint in SharePoint farms and Exchange servers
• SharePoint In-Place hold: SharePoint In-Place hold will keep all SharePoint sites. It protects all the pages, documents, list items in the site and allows users to edit and delete the content.
• Exchange In-Place hold: like SharePoint In-Place hold, Exchange In-Place hold will keep exchange mail boxes. It protects all the mail box content as same UI and API uses for SharePoint In-Place hold.
• Query Based Preservation: it allows users to apply query filters to exchange mail boxes and SharePoint sites.

 

We have eDiscovery site collection in SharePoint 2013, contains identification, preservation, processing and analysis. eDiscovery center is also available in Office 365 site and can be connected to exchange. So that we can conduct the eDiscovery in SharePoint site and Exchange, Lync. In eDiscovery site collection we can create case sites that used for manage in-place holds and queries. 
 

Making SharePoint Information Architecture Work for You

Information architecture shouldn’t be a big scary thing: it’s simply about creating the same elegance you see in the Golden Gate Bridge or the Eiffel Tower, only instead of being built with steel, it is built with information.

What is Information Architecture?

 

Information architecture is the process of creating a structure and tools for information such that it can be stored, retrieved, and managed efficiently and effectively. In other words, information architecture is about making information work for you.

Information architecture is different than physical architecture as there aren’t physical materials to arrange. However, the struggle towards effective and simple elegance, which is at the heart of all architecture, has its place in information architecture as well.

When speaking of architecture, we should mention the architect, the person who is responsible. In Greek, the word architect means the chief builder. However, a building architect doesn’t actually build the building. Carpenters and skilled tradesmen do that. An architect, then, is the person who creates the plans, strategies, and direction for the building.

Going back to our case of information, the primary tool the architect uses is “creating meaningful breakdowns.” That is, the architect creates the ability to find information by categorizing it. The following five steps are a straightforward approach to generating your information architecture.

 

Step #1: Identify Attributes

As humans we use chunking, or treating multiple things like a group, so that we can cope with the sensory and information overload that’s happening all around us. If we want to create groups, we need to create attributes and values to group on. The first step is to identify the sea of available attributes. This in and of itself requires that you develop a way to organize the attributes that you identify, because there will be a few.

Identifying the attributes is typically a process of identifying all of the content in your organization that people want to store and find. This might include invoices, purchase orders, time sheets, et cetera. Each of these has a series of attributes such as the invoice date, customer ID, or vendor ID. These may be valuable for organizing the information for retrieval.

One of the cautions in this exercise is that you’ll try to identify every attribute on every piece of content in the organization. While the exercise is in capturing the attributes and the content types, the assumption is that you’ll never be complete and more importantly, you can come back and extend your inventory of attributes later. Your goal is to get the most important attributes down and allow the others to surface if they’re important.

 

Step #2: Identify Essential Attributes

Once you have an inventory of attributes it’s time to figure out which ones really matter. Attributes of any object or piece of information can be sorted into two categories: essential and accidental. It’s essential that a car has four wheels and that a plane fly: number of wheels and modes of transportation are essential attributes. (No, I don’t count three wheeled vehicles as cars.) The color of the car—say, red—and the construction of the airplane—say carbon fiber—are accidental properties.They just happen to be that way.

Essential attributes are used for top levels in a hierarchy. They are at the top of the hierarchy (or hierarchies) because they’re the ones that are easiest for people to identify with.

 

Step #3: Identify Values

 

Knowing what the attributes are is a good start, but you still have to get to specific values. For instance, what are the colors? Red, blue, or green?
Are you generally referring to color by its rough category, its Pantone number or its marketing name? What are you going to standardize on for the way that you identify colors? This is a game of standardization and specificity.

Specificity is how specific your values are. Red is a generic color. Pantone 1935C is a specific representation of a red color. If your business is printing, you’ll probably need the specificity of Pantone colors, andif you’re in the business of making wagons, red is probably specific enough.

 

Step #4: Create Ranges and Groups

Sometimes you can create groups based on the number of values for an attribute. If you have ten color categories that you’re dealing with, the color categories can be your options.
However, if you’re using Pantone colors, which number over 1000, doesn’t make a good set of options for users to choose from in a single menu. To create an information architecture you’ll need to create a set of meaningful breakdowns.

In the colors you may need to create groups based around the primary colors (red, yellow, and blue) or more likely primary and secondary colors (red, orange, yellow, green, blue, and purple). The fun will be in organizing the colors into these groupings since the boundaries will be somewhat arbitrary.
One solution to this: create a poly hierarchy where each color is placed in more than one of these categories. This reduces the specificity (reduction capabilities) of the choice but maximizes the chance that a user will find the color they’re looking for.

 

Step #5: Design Navigation and Search

 

The final step with building an information architecture is in connecting it to the visual design. This includes the development of navigation solutions that help the user get to the right information.

The convention of a global navigation across the top and local navigation in the left column is pretty set. Utility navigation, the stuff about how to use the site, is less standardized but also less interesting.
Information architects are most likely to focus on content navigation: helping content authors connect one piece of content with other pieces of content.

Content navigation is built into SharePoint in terms of summary links, but creative use of search can automate some level of the massive task of adding content navigation. For instance, you can add a search web part, which shows all articles authored by the same author, on the same topic, or around the same time.

The design of search itself is mostly about which attributes will be able to be used as facets to refine searches but will include the creation of scopes to create different subsets of the search index in which people can find their answers.

 

Take it Step by Step

Information architecture doesn’t need to be scary. These steps will put you on the right track to creating an information architecture you can be proud of.

SharePoint 2013 has reached RTM

 

Earlier today Microsoft announced that Office 2013, including SharePoint Server 2013, reached the Release to Manufacturing (RTM) build.  That means that coding and testing is complete and work will now commence on getting these products packaged up and into the appropriate distribution channels for customers.  You can read the full announcement here: 

Office Reaches RTM!

 

 

SharePoint 2013 Top 10 New Features

Here are some Top Features of SharePoint 2013 that will start to sell your business on investigating the Preview. All of these features are documented in TechNet. I'll do a Top 10 for each audience as more information becomes available.

1. Support the tools designers use: Flexibility in Branding – How great will it be that your designers can use Dreamweaver or other popular design products. More information on TechNet Branding Features
   "Whether that is Adobe Dreamweaver, Microsoft Expression Web, or some other HTML editor. To brand a SharePoint site, designers just create a site design as they typically would, by implementing HTML, CSS, and JavaScript"
2. Offline and Sync of My Site (and other libraries) – "In SharePoint Server 2013 Preview, My Sites include several improvements to saving, synchronization, sharing, and moving of content. Users have the option to synchronize their My Site document library content with a local drive to enable offline access to documents." Saving and Syncing Content (I really love the new Follow people, documents, sites, and tags to customize their feed!!)
3. Search Engine Optimization & Analytics is in Search – Search is TONS better. Much of this is due to Analytics moving into search. This will make Analytics Processing Component in SharePoint Server 2013 Preview runs different analytics jobs to analyze content in the search index and user actions that were performed on a site to identify items that users perceive as more relevant than others. TechNet Analytics Recommendations
4. Content Search WebPart – This webpart is cool, but it may take a demo to understand the power. In many ways this is the next generation of Content Query Web Part. "Content Search Web Part that displays content that was crawled and added to the search index. You can use category pages when you want to aggregate content that meets certain criteria or parameters. For example, in an intranet scenario, all company events are maintained in a list that is shared as a catalog. A query is issued from the Content Search Web Part to return all items from the search index that are specified in the query." Content Search Web Part
5. Optimized mobile browser experience – For some companies this may be the reason to upgrade alone. Mobile is definitely something I have been looking for. "For smartphone mobile devices SharePoint Server 2013 Preview provides a lightweight, contemporary view browsing experience for users to navigate and access document libraries, lists, wikis, and Web Parts. Contemporary view.  This view offers an optimized mobile browser experience to users and renders in HTML5. This view is available to Mobile Internet Explorer version 9.0 or later versions for Windows Phone 7.5, Safari version 4.0 or later versions for iPhone 4.0, and the Android browser for Android 4.0. Classic view   This view renders in HTML format, or similar markup languages (CHTML, WML, and so on), and provides backward compatibility for mobile browsers that cannot render in the new contemporary view" Mobile browser experience Device specific Master Pages – You can target your branding to the device! Targeting different devices such as smartphones, tablets. "Allow a single publishing site to be rendered in multiple ways by using different designs that target different devices." TechNet Device Specific Branding Feature
6. Rich Workflows – If workflows were a sore point, they've gotten a lot better and seem much more able to handle more complex activities including looping and working with webservices (anyone thinking orchestration?). "A new action that enables no-code web service calls from within a workflow, New actions for creating a task and starting a task process and New workflow building blocks such as Stage, Loop, and App Step" With Azure Workflows you can even do "REST and Service Bus Messaging" Workflow in SharePoint 2013 Machine Translation – Looking forward to really seeing what our business can do with this translation service. Automated translation into various languages!
7. Development gets more familiar – Developers who are not SharePoint developers will find SharePoint 2013 preview a lot easier to work with. Leverage your existing "ASP.NET, Apache, C#, Java, and PHP. The new cloud app model gives you the freedom of choice." Familiar development environments
8. New App Model – This new app model will take you into the New Online World – "The new app model embraces web standards: You can develop the user experience with HTML and JavaScript, and leverage SharePoint and other REST services right from the client using JavaScript and JSON. You can even create your own REST services and provide a web hosting platform of your choice to handle complex logic and integration of data and services. The new cloud app model also takes advantage of OAuth to allow for secure communication between SharePoint and remote hosted apps and services." Familiar tools – App Model
9. Shredded Storage – This is one of my favorite new features. I can't wait to see what it does to our farm. Shredded storage will remove file duplicates and reduce the amount of content sent across the wire. You can find more on this in the IT pro decks.
10. Social Features: Activity feeds – I really like the idea that I can get real notifications of what's happening on a site including following documents, following sites, and following people… and automatically following team members (if you want). Communities – I think Microsoft's new site template communities will be interesting with integrated microblogging. I'm definitely anxious to see how our internal communities use them. What's new in social computing

SharePoint 2013 Changes

What is SharePoint 2013
A new version of Microsoft famous Collaboration portal called SharePoint. The version adds few new exciting features such as Social Feed,SharePoint Apps and cross-site publishing.

Development Changes

• In SharePoint 2013 Microsoft Introduced a new Cloud App Model for designing Apps for SharePoint. Apps for SharePoint are self-contained pieces of functionality that extend the capabilities of a SharePoint website. You can use HTML, CSS, JavaScript and protocols like the Open Data protocol (OData), and OAuth to communicate with SharePoint using Apps.
• Tools – SharePoint 2013 has Introduced new Tools for App development. Visual Studio 2012 now lets you develop apps for SharePoint and apps for Office. In addition a new web-based tools called “Napa” Office 365 Development Tools were introduced for developing apps.
• No more Sandbox solutions. SharePoint 2013 sandboxed solutions are deprecated. So all we got is the New App model and the Old SharePoint Farm solutions.
  

Social and Collaboration features 
Microsoft in SharePoint 2013 Introduced new Social capabilities for better collaboration in the company.New Features added are -

• Interactive feed.
• Community Site.
• Follow people.
• Follow Sites.

Search - SharePoint 2013 includes several enhancements, custom content processing with the Content Enrichment web service, and a new framework for presenting search result types. Some of the features added are 

• Consolidated Search Results.
• Rich Results Framework.
• keyword query language (KQL) enhancements.

Enterprise Content Management (ECM)
SharePoint 2013 added some of the best capabilities of an ECM software. The newly added stuff is

• Design Manager.
• Managed Navigation.
• Cross-site Publishing.
• EDiscovery.

SharePoint: SQL Server Design Tips

SQL Server databases are the largest consumers of disk space in SharePoint. Thus, designing your disk system for maximum performance at the database level is more crucial than for any other level. Here are some general design tips.

Don't virtualize SQL Server. If possible, don't virtualize SQL Server because it's already an integration platform. If you have to virtualize SQL Server, try to limit the virtualization to test or development systems. Avoid using it for production systems because it raises the bar in disk engineering to get good performance. SQL Server databases stored in virtualized disk files are inherently slow compared with dedicated physical disks.

Use multiple logical drive letters. It's usually a good idea to break up SQL Server databases into multiple logical drive letters because database files, transaction logs, backup files, and temporary databases (tempdb) benefit from having multiple independent sets of disk spindles. Adding more spindles spreads the load across multiple parallel operations when data is being written to the database.

If you're going to use a SAN or virtualized environment, make sure you understand where those logical drive letters will be mapped. For example, if the D, E, and F drives will all point back to separate LUNs on your SAN, but those LUNs will be part of the same storage group and same set of physical disks, splitting those files into multiple drive letters will add complexity without significant performance gains.

Use RAID 10 judiciously. RAID 10 is great, but you might not be able to justify it for all applications. For example, it might be overkill for backup files. Balancing disk performance and cost is a reasonable trade-off. One possible design is to use:

• RAID 1 on boot disks
• RAID 5 on data disks
• RAID 10 on log disks
• No RAID or RAID 5 on backup disks

Break large content databases into multiple database files. If you have large content databases, you can engineer better performance by breaking each large database into multiple database files. Each database file should be on a separate disk.

Presize SQL Server databases. SQL Server databases can be set to automatically grow as needed, but this can lead to massive file fragmentation. Presizing the databases to a sufficient size at the outset helps ensure contiguous file allocations. Note that SQL Server's tempdb database is heavily used by SharePoint, so you should presize it to about 20 percent of the size of the single largest content database.

If you want to use automatic database growth settings instead of presizing your databases, you should set the databases to grow in 50MB to 100MB clumps and not by percentage. Setting a 100GB database to grow in 10 percent increments means the database essentially stops to add 10GB or more on each increment. Using a small clump size will lead to more frequent, but smoother, steady state (i.e., continuous) growth.


Design a High Performance Database Environment


If you use RAID and follow the general design tips, you can design a high-performance database environment that's also highly available. This is essential to a smoothly running SharePoint system.

Top 10 SharePoint 2010 Configuration Mistakes

1: Scrimping on SharePoint's RAM or Hard Disk Space

A poor, defenseless SharePoint server working as hard as it can to keep users happy, but having its hands tied because of limited resources. This situation is usually a casualty of aggressive virtualization. Virtualization itself isn't bad, but it must be done intelligently and without sacrificing SharePoint's ability to do its job.

If SharePoint finds itself starved for RAM, it starts shutting off functionality so that it can fit into the available space. It also caches less in the web application pools and recycles those pools more often. Less caching and more recycles result in a degraded end-user experience, as SharePoint must compile the same ASP.NET code over and over. And no one likes unhappy users, not even their mothers.
The solution to this particular issue is easy: Add RAM. Microsoft has published the hardware requirements for SharePoint 2010 in the TechNet article "Hardware and software requirements (SharePoint Server 2010)."  These requirements state that at the very least, each SharePoint 2010 production server should have 8GB of RAM and a C drive with at least 80GB. In many cases, that won't be enough. If your servers are in production, you can watch their memory utilization to see whether they use the entire 8GB of RAM. If so, they could use more. If your servers are not yet in production, you can use a variety of load-testing tools to simulate your intended load and see how the servers hold up. For example, you can download the Microsoft Load Testing Kit, part of the SharePoint Administration Toolkit.

As for your C drive, SharePoint itself doesn't need much space, but Windows does. After all, your server has several years of Windows patches to look forward to. While you're adding drive space to your machine, consider adding a secondary drive as well. This drive is a great place to store all the files that you use when you install SharePoint. All the third-party installation files can go there too. You can also have SharePoint put its log and Search index files on this drive. This approach takes some pressure off the C drive. Happy C drive and happy end users equal a happy SharePoint server administrator.

2: Using Virtualized Microsoft SQL Server

Virtualization isn't bad. But virtualization allows administrators to make mistakes on a much grander scale. Take virtualizing SQL Server. In the context of SharePoint, this process can be especially painful. The main mistake I see when virtualizing SQL Server is overcommitting the host, be it through RAM, CPU, or drive space. Because everything in SharePoint is stored in SQL Server, if SQL Server is slow, SharePoint is slow.

The obvious solution is to move SQL Server to a physical box, on which it doesn't need to share resources. Moving SharePoint's SQL Server instance is easy, thanks to aliases. This process outlined with pictures, at www.toddklindt.com/sqlalias.

If you can't get a physical SQL Server box, then at the very least ensure that your virtualized SQL Server instance has a fighting chance. First, make sure that its virtual drives aren't thin provisioned. I/O is one of the areas in which virtualized SQL Server struggles the most, and thin-provisioned drives exacerbate that problem. Also try to put the SQL Server guests' virtual drives on their own spindles on the host. Doing so should improve I/O by preventing SQL Server from fighting other guests for time with the drives. Finally, you shouldn't allow the virtualization host to overcommit its RAM. If the host must swap to meet its RAM obligations, then it's slowing down SQL Server.

Brent Ozar has recorded a brilliant video on how best to virtualize SQL. Go get some wine and pizza, invite your fellow SharePoint admins, dim the lights, and watch that video. You'll learn a lot.

3: Using the Farm Configuration Wizard

 

Using the Farm Configuration Wizard was a pretty common mistake when SharePoint 2010 first came out but thankfully has diminished as our familiarization with SharePoint 2010 has increased. The wizard's list of atrocities is long, so I'll just cover some of the better known ones. First, and maybe most heinous, is that all the databases that the wizard creates have nasty globally unique identifiers (GUIDs) at the end of their names. The wizard also creates a content web app, at http://servername, that just doesn't scale well. To add insult to injury, the wizard creates your My Site host on that same web app, at http://servername/my. Finally, the wizard encourages you to create service applications that you might not actually use. It's tough to resist the siren song of those check boxes, I know. 


The Farm Configuration wizard leaves its dirty handprints all over SharePoint, and it can be a challenge to clean up all of them. However, a few places can be easily fixed. Start with your web apps. Create a web app for My Site and give it a Fully Qualified Domain Name (FQDN), such as mysites.company.com. Create a My Site host at the web app's root. Use the Windows PowerShell cmdlet Move-SPSite to move any My Site to one content database, and then attach that content database to your new web app. You'll also need to adjust your User Profile Service and tell it about your new My Site location.

Next, clean up your service applications. Go through your list of service applications and delete any that you aren't using. You gain no benefit from having a service application that you aren't going to use for another six months. After you've deleted unnecessary service applications, stop the associated service instances (also called services on server) that power them. If possible, remove the GUIDs from the service application database names. The technique for completing these tasks varies among service application; the Microsoft article "Rename or Move Service Application Databases (SharePoint Server 2010)"  has directions for all the service applications. Of course, take good backups before doing any of this.

4: Using an Incorrect URL when Creating a Content Web App

 

Like any relationship, SharePoint and Microsoft IIS have communication problems from time to time. Web app creation is one of those times. SharePoint doesn't tell IIS about changes that you might make to a web app after it is created. For instance, if you create an Alternate Access Mapping (AAM) for a web app in Central Administration, you still need to go into IIS and add the host header for the new address.

The issue is compounded when SharePoint farms that you never thought would need to be accessible from the Internet suddenly need to be accessible from the Internet. Budding SharePoint administrators commonly give their web apps short URLs, such as http://portal, to save users some typing. Of course, that URL doesn't route across the Internet, so the web app needs a fully qualified URL added to its stable of AAMs. Not only is this new URL not written to the IIS host headers, but it's also missing from all the alerts, workflows, and anything else that saves URLs -- all those items have the old URL hard-coded in. Because SharePoint didn't write any additional URLs to IIS when they were created, it won't write them to any new SharePoint servers that are added to the farm. Nor will SharePoint write these changes to IIS if the Microsoft SharePoint Foundation Web Application service instance is stopped and started.

This issue might not seem like a big deal, but it has bitten many people at the worst possible time: during an outage. In a few cases, administrators have lost or needed to rebuild a SharePoint server and forgotten about the host headers that they put in manually months earlier. SharePoint is up and going, but when browsing to SharePoint, end users get the blue IIS 7 splash page instead of the SharePoint page that they were expecting. Again, unhappy users usually mean unhappy administrators.

Because SharePoint writes host headers only when a web app is created, you can't fix problematic web apps. You'll need to recreate them. That's good news and bad news. The good news is that you won't lose any of the content that your users worked so hard to create. The bad news is that you will lose all the settings that you worked so hard to create.

The first step is to make notes of all your web app settings. In most cases, there won't be many, and you'll be familiar with any changes that you made. Then, detach the content databases from your web app. Keep them safe; you're going to need them. Next, make a copy of the web.config file for that web application. Some settings, such as forms-based authentication (FBA) and BLOB cache settings, are in that file. Finally, go into Central Administration and delete the web app. Tell SharePoint to delete the extra stuff. The scary part is over.

Now, recreate the web app, but do it right this time. First, enter the correct, fully qualified URL in the Host Header box. Do your end users a favor, and put the web app on port 80, as Figure 1 shows. Under the Security Configuration settings, accept all the defaults, even if you're going to use Kerberos or SSL. You can change those settings later, and you want to make sure that the web app works correctly before you apply fancy security settings. Doing so helps in any troubleshooting that you might need to do. Under the Application Pool settings, pick an existing application pool.

It is important to give your content databases distinct names. You should be able to look at a content database name and know exactly which web app that database goes with. This is another one of those things that doesn't usually seem important but is priceless in a disaster-recovery situation. If the content databases that you detached from the web app before you deleted it didn't have such names, then take this opportunity to right that wrong when you recreate the web app. Give the new content database a good name, then use the PowerShell cmdlet Move-SPSite to move the site collections to that new database. If your content database already has a good name, enter it during the creation of the new web app. If you had multiple content databases, attach the rest after the web app is created.
After the web app is created, you can tweak settings as needed. Most settings can be changed in Central Administration. If you made any changes to the web.config file of the original web app, now is the time to copy those changes to the newly created web.config file. You can use a program such as Notepad++  to compare the two files. You should now have a well-created web application that you can trust in times of crisis. 

5: Running Web Apps or Service Apps in Separate App Pools 

Web apps and service applications run inside of an application pool, which is a W3WP.exe process that runs on your server. Unless you have reason to do otherwise, you should run all SharePoint web apps inside one application pool; the same goes for the service applications. Running each web app in its own application pool makes inefficient use of the server's memory. Each application pool has a minimum overhead of more than 100MB, and its memory footprint increases as it caches content that's rendered frequently. Figure 2 shows multiple W3WP.exe processes running as sp_webapps, the result of web apps running in separate application pools. We've all experienced SharePoint slowing first thing in the morning because the app pools recycle overnight and need to warm up and cache that content again. Well, multiple application pools mean that the same content is cached multiple times. Most users are impatient. I'm sure that studies would show that they spend the time waiting for SharePoint to respond by thinking of ways to punish us for SharePoint's poor performance. 

For service applications, this problem is easy to fix. First, make sure that you have a good service application pool to use. I recommend calling this pool Default SharePoint Service App Pool so that it floats to the top of all your drop-down lists. Use a dedicated sp_serviceapps account for the pool's identity. Most service applications allow you to assign them to a new service application pool by modifying their properties in Central Administration. If the option is unavailable there, look for it in PowerShell.

Web applications are a tougher matter. There's no easy, out-of-the-box way to change the application pool that a web app is using. Fortunately, we have PowerShell at our disposal.

6: Using One Account for Everything 

 

Security is complicated, and SharePoint doesn't necessarily make it any easier. Using just one account -- maybe even the coveted Domain Administrator account -- is so easy. We've all done it, even though it's a bad idea. When you use an existing account, you open up SharePoint to several security issues. Anyone who knows the account password can do anything in SharePoint, so you can't separate duties. You also lose the ability to audit who made which changes. And if that common account password is compromised or needs to be changed, you jeopardize SharePoint's uptime as well. Even if you use one dedicated account for SharePoint, you leave yourself vulnerable to attack. If that account is compromised via a security exploit, the bad guys will have access to everything in SharePoint.

To fix this mistake, start by creating the accounts. Add the sp_webapps and sp_serviceapps accounts as managed accounts. Use the techniques that describe in Mistake  No 5 to fix your web app and service application accounts. You can change the default content access account for the Search service application at the Search Service Application page. Under Central Administration, Security, Configure Service Accounts, you can change the accounts that other processes use as well. (You can even change the Farm Account there. I've done so in test environments but haven't been brave enough to do it in production.) If you're using the User Profile Service, make sure that your new sp_userprofile account has the correct permissions in Active Directory (AD), and recreate your AD connection in the User Profile Service.

7: Keeping Default SharePoint Database Settings

 

When SharePoint creates its multitudes of databases, it makes some bad assumptions. Take the autogrow settings: The database files grow by 1MB at a chunk, almost ensuring that they're going to autogrow with every upload. Not only does this slow down SQL Server (which slows down SharePoint), but it also results in database files that are spread all over your drives in itty-bitty 1MB chunks.

SharePoint also creates most of its databases, notably the Config and Content databases, with the recovery model set to Full. Although this is great if you want to recover data, you must manage the process correctly or those sneaky .ldf files will slowly, methodically fill your hard disk. If you think users get upset when SharePoint is slow because of fragmented databases, you should see how angry they get when SharePoint stops completely because the SQL Server drives are full.

To fix this mistake, set your databases' autogrow settings in such a way that they don't need to grow frequently. For most farms, I recommend changing the 1MB autogrow to something like 500MB or 1GB. Autogrow should also be a last resort. Someone, either the SharePoint administrator or a dedicated DBA, should pregrow your databases so that autogrow is unnecessary.

Your recovery model setting needs to be consistent with your disaster recovery plans. If you need your transaction logs, make sure you're performing routine log backups to keep those .ldf files in check. If you don't need your transaction logs, then consider switching your databases to the simple recovery model. Doing so will keep your .ldf files from swelling up like a nasty bee sting.

8: Not Enabling BLOB Caching

 

We all want SharePoint to get files to the users as quickly as possible. However, more often than not, I see SharePoint farms without BLOB caching enabled. BLOB caching is one of the easiest and least expensive ways to improve SharePoint performance. Not only does it help to get files to users more quickly, but it also eases the burden on SQL Server. Everybody wins.

This might be the easiest solution so far: Enable BLOB caching, of course! BLOB caching is actually a function of IIS; SharePoint just takes advantage of it. Therefore, to enable BLOB caching requires a change to each web app's web.config file on each server. Fortunately, the setting already exists and just needs to be enabled. By default, the web.config files are in a directory under C:\inetpub\wwwroot\wss\virtualdirectories. Each web app has a directory and a web.config file. Open one of these files and look for the following line:


<BlobCache location="C:\blobcache\14" path="\.(gif|jpg|jpeg|jpe|jfif|
bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|
mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="false" />

To enable BLOB caching, replace "false" with "true" and save the web.config file. You should also move the file to a directory on a drive other than the C drive. The maxSize parameter is measured in gigabytes, with a default of 10GB. If the space is available, you might want to increase this size.
If editing this file in Notepad on all your servers isn't your idea of fun, you can use PowerShell to automate the process. You still need to perform the process on each server, but using PowerShell is quicker and reduces the chances of a mistake.

9: Not Installing a PDF iFilter 

 

Most organizations have a tremendous number of PDF files in their SharePoint farms, and those files represent a wealth of information. End users want to be able to discover that information by using SharePoint Search. Getting users excited about SharePoint Search is a great way to get them excited about SharePoint in general.
Installing a PDF iFilter is fairly easy. Adobe has a free PDF iFilter that you can install. You can find the download link and detailed installation instructions in the Microsoft article "SharePoint 2010 - Configuring Adobe PDF iFilter 9 for 64-bit platforms." You need to install the iFilter only on those SharePoint servers that run the Search Index role, although installing it on the rest of your SharePoint servers doesn't hurt. If you have a large farm and want to reduce the time needed to index your PDF files, you can use the PDF iFilter from Foxit. This product has better performance than the Adobe iFilter but isn't free.

10: Not Pointing Your SharePoint Servers at Themselves

 

When SharePoint works, it is magnificent. When it doesn't work, it can be a nightmare to fix. For this reason, anything you can do to ease troubleshooting is time well spent. To that end, I make sure that every server in the SharePoint farm points to itself for all web apps. If I get sporadic reports about SharePoint not responding, I can easily use RDP to log in to each server and try to pull up SharePoint. If this attempt works, then I know that the server is working. If SharePoint does not come up, then I know in exactly which Microsoft User Location Server (ULS) logs to look for the relevant errors. No worrying about which web front end the load balancer sent my request to. The quicker you get to the correct log files, the quicker the problem is resolved.
Pointing your Search indexer at itself has another advantage: It improves performance for your end users. If you don't point your Search server at itself, then when it starts to perform a crawl, it lets DNS do its work and then starts crawling whichever web front end DNS points it to. That server is most likely the same one that is sending pages to your end users. Making the server do double-duty means that everyone waits longer. Pointing the Search server at itself means that your web front end doesn't need to handle that traffic and can get back to doing its #1 job: keeping users happy.
There is a simple fix for this mistake: Open the hosts file (C:\windows\system32\drivers\etc\hosts) on each SharePoint box, and add all the URLs that SharePoint knows about. Point those URLs to 127.0.0.1, which translates to "this computer." Figure 3 shows how this file looks in a typical SharePoint environment.

 

 

 

 

SharePoint 2010 Service Account

Account name	Role	Domain rights	Local SharePoint Server rights needed	SQL rights needed
sp_install	Used to install SharePoint binaries.	Domain User	Local administrator on all SharePoint boxes	dbcreator and securityadmin SQL roles
sp_farm	Farm account. Used for Windows Timer Service, Central Admin and User Profile service	Domain User	Local Admin during UPS provisioning, log on locally right	None
sp_webapp	App pool id for content web apps	Domain User	None	None
sp_serviceapps	Service app pool id	Domain User	None	None, unless using Office Web Apps. Them must give access to content databases manually
sp_search	Search process id	Domain User	None	None
sp_content	Account used to crawl content	Domain User	None	None
sp_userprofile	Account used by the User Profile services to access Active Directory	Must have Replicating Change permissions to AD. Must be given in BOTH ADUC and ADSIEDIT. If domain is Windows 2003 or early, must also be a member of the "Pre-Windows 2000" built-in group.	None	None
sp_superuser	Cache account	Domain User	Web application Policy Full Control Web application super account setting	None
sp_superreader	Cache account	Domain User	Web application Policy Full read Web application super reader account setting	None

See http://technet.microsoft.com/en-us/library/ee721049.aspx 

Again, these are just recommendations. You may end up using more accounts if you have multiple application pools, for instance. Your particular farm may require different accounts.