Tag: Governance

SharePoint Quota Management

SharePoint ships with a decent set of Quota Management tools. Many of the people I talk to are not familiar with the tools because they do not believe they need quotas. I think the tools offer valuable information that can be used to help maintain a well run farm even if strict quota management is not needed. Without the tools, you increase the likelihood of excess content being stored which leads to longer backup and recovery times and additional storage needs.

If sites really do not need to be limited, I would advocate setting the quota limits very high as opposed to not enabling them or turning them off.

Storage Space Allocation Report
The tools are available to Site Collection Administrators from the Site Settings page at the root of the Site Collection.

The tools will list out all of the content in the Site Collection. You can review Document Libraries, Documents, Lists, and the Recycle Bin.

Document Libraries – I find it helpful to know which libraries have the most content. By reviewing this list you can get an idea of which Document Libraries to target when reviewing the information architecture and taxonomy issues. This may also provide the information needed to make decisions on restructuring sites and site collections so that they are smaller and nimbler helping to reduce recovery time during disaster recovery.

Documents – It can also be informative to know how big the bigger documents are. This report will actually roll in prior versions as well so if there are a large number of versions you can review and clean up as needed. In the prior version of SharePoint it was not possible to set a maximum number of versions to save so I used this to review and manage prior versions. I had one case where there were some financial spreadsheets with over 100 versions at 75mb each. That is just wasted space unless there is a real business need.

Lists – List size can be very difficult to figure out without this tool. The number of records is important to know, but if there are attachments the list size can grow very quickly. This report will detail both the number of items, as well as the storage space consumed.

Recycle Bin – It will also report out what is in the recycle bin. There is nothing too exciting here.

How to Manage Quota Templates
The quota templates are available in Central Administration under Application Management, Quota Templates.

If you do not really want to manage quotas you can set this to a large value. If you have a charge back system in place where groups pay for the storage they use, try to identify a few different standard categories and assign a warning and max level. Here are some categories that I have used before.

• Personal Sites
• Personal Sites – Executive
• Medium Document Storage
• Heavy Document Storage
• Light Collaboration
• Medium Collaboration
• Heavy Collaboration

How to Enable Quota Management
The screen to enable quota management on a site collection is available in Central Administration under Application Management, Site Collection Quotas and Locks.

Note: If a site goes over its configured quota it will be set to locked. Even if you adjust the quota size you will still need to remove the lock.

Managing SharePoint Customizations and Change Log

In previous posts I wrote about SharePoint Customization Policies and Change Control. That post was pretty high level and at its root questioned the position of some environments that set a No Customization policy. It then gave a brief overview of the types of customizations and how they differ from content changes.

I wanted to follow up with a post that goes a bit more in detail how to manage an environment that does allow customizations along with some suggestions on how to document and manage those customizations.

Packaging Custom Code
Most SharePoint developers start out as regular .NET developers. It is a natural progression and there are a lot of similarities. One big difference comes in deploying solutions. Most try to manually deploy their solutions, not understanding all of the implications. In order to gain all of the benefits of the SharePoint platform code needs to be bundled into packages. Simple, stand-alone web parts can be packaged and deployed via cab files and more sophisticated apps, templates, and timer jobs can be deployed via SharePoint Solution files.

By packaging and deploying these customizations through supported interfaces they will be easier to manage during updates and when adding additional Web Front Ends to your farm.

Targeting Custom Code
Not all solutions or web parts have to be deployed globally throughout the farm. If your solution or web part is used to support a specific application then only deploy it to the site(s) that need it. That will reduce clutter in the solution listings or Web Part catalog.

Tracking Installations and Deployments
It is a very good idea to keep a running list of the patches, components, and customizations installed. This can make troubleshooting issues a lot easier, and help make migrations or farm changes easier. I keep a site within my SharePoint farms to manage the change log and documentation.

Some data elements that I would recommend tracking include:
• Title
• Description
• Requester
• SolType (WP, List Tmpl, Site Tmpl, WF Actions, Timer Jobs, Sys Patch)
• Source (Custom, Community, 3rd Party)
• Install Date
• Current Version
• Scope (Farm, Application, Site Collection)
• Scope Detail
• Additional Details

Related Articles
SharePoint Customization Policies and Change Control
Managing SharePoint Solutions and Extensions

Managing SharePoint Solutions and Extensions

One of the great things about SharePoint today is the incredible traction that the platform has gained. The depth and range of solutions now offered by vendors along with open source solutions offered by the community really is amazing. It was a different place when I first installed SharePoint Portal Server 2001 back in early 2002.

Browsing the CodePlex I often feel like a kid in a candy store. So many great solutions, I cannot wait to install them all! Well not so fast, it might be a good idea to take a step back and consider the consequences.

Deciding What to Install
One key to maintaining a well run environment is to have a process in place to review, approve, and manage customizations. This should be part of your formal governance plan, but if you do not have one do not let that stop you from looking at this particular topic and working out some plans.

Special care should be given to non-commercial solutions. They should always be tested in a non-production environment before being deployed to your production environment. When downloading community code, be sure to take notice of who is contributing it and what the official release is. CodePlex for example does a great job of showing build info and release notes. If an item is marked as Alpha or Beta it probably has not been put through rigorous testing yet. If you want to use it then make sure you are comfortable with the risks and test it in your environment.

Testing Environment
Your test environment should be as similar to your production environment as possible. You do not necessarily have to put it on the same quality of hardware, but the configuration should be similar. It is critical that the patch levels are the same. On this note, you should be testing any KB Patches, MS Cumulative Updates, or Service Packs anyway.

Make sure that the test environment also includes the full catalog of Solutions, Web Parts, and other customizations. This is important because it is possible that one might conflict with another. Unit Testing is not enough, you will want to see how it will react and interact with your environment.

Potential Problems or Conflicts
Depending on what functionality the solution provides, the problems or conflicts can range quite a bit. Knowing what is installed is a good start.

While there is a chance that something could break independently, most of the issues I have seen came from trying to migrate, patch, or upgrade a site.

Site Migration – When migrating a site from one environment to another, it can be a pain to find out half way through that you need to install additional site templates or web parts on the target server.

Patch – When completing the installation of a Patch, Cumulative Update, or Service Pack you normally have to finish the upgrade by running either the Configuration Wizard or the PSConfig command line app. This can be a pretty stressful exercise, and no fun comes from seeing it fail along the way. I have had customizations cause problems here, particularly when changes were made directly to the web.config file as some solutions require. Having your documentation on hand will help you get through the mess and cut down on the time it takes to complete the upgrade.

Future Versions – You also need to consider the likelihood that the solution will be maintained going forward. When I made the jump from WSS 2.0 and SPS 2003 to the current version WSS 3.0 and MOSS many of the solutions I had been using did not make the jump. Some of it was because of the code base changing from .NET version 1.1 to 2.0 and some of it was because Microsoft added parts of the functionality to the platform so vendor no longer wanted to support the products. End users are not necessarily going to care why they do what they used to do, they will only care that they cannot do it. Mitigate the risk by communicating to the stakeholders the potential problems.

It has already been noted that Service Pack 2 will include an upgrade readiness check to help identify any potential problems upgrade to the next version. I would recommend taking the time to go through this check after SP2 is installed, and then checking it again after you install any new solutions before making the jump to the new release.

Summary
By putting together a plan to review, test, and approve add-on solutions you will decrease the likelihood of problems in your environment and decrease the time it will take to respond to issues when they do come up.

Impact of SharePoint Designer Free Distribution

This week it was announced that SharePoint Designer 2007 and future versions are now freely distributed.

Announcement

Download

The developer community was quick to applaud the news since this is a useful tool, but I assume also because getting software purchases approved in the current economy is difficult at best even in stable companies.

The news however brought a different set of comments from the system administrators and IT management folks who are worried about what the ramifications will be. They are right to be worried. Many companies are already struggling with governance and end user site ownership issues. With that in mind I think it gives them that much more incentive to get their policies, procedures, and training plans in order.

From a Program Management perspective, I think it is critical to the platform to enable end user groups to design, manage, and interact with their own content. That includes maintaining their own access control lists (ACLs), libraries, lists, and design their own workflows. I see SharePoint Designer as an extension of the platform, not much different than MS Word or Excel. Site Owners and Designers need to be able to manage this in most situations.

In a medium to large organization it would take an army of IT team members to manage this for every group, it is just not feasible and not the purpose of the SharePoint platform.

So how should you proceed?
Governance – Address custom design and development in your Governance plan. Determine who can have it, and what it can be used for.

Training – Address its use in your training plan, and make sure that Design and Developer resources are available. Perhaps you can pick up a copy or two of Professional Microsoft Office SharePoint Designer 2007 (Wrox Programmer to Programmer).

SharePoint Designer Collaboration Site – Provide site owners with a place to collaborate and provide guidance. You can include samples, links, and FAQs to help them.

Through proper governance you can help guide their decisions and enable their success. Their success and approval leads to the success of the platform in your organization.

What can be done to prevent use of Designer?
Installation – For now you can look at local computer policy and prevent installation of unapproved software. For people in companies that already do this, they know that it takes a lot to manage that.

Security – You can also review site security and make sure that the appropriate set of users have access to make changes.

Disable at the Site Level – There is some work in the community right now to come up with a solution to prevent specified sites from being changed or customized with SharePoint Designer.

UPDATED: John Ferringer and Brian Farnhill have posted a Beta for the project, setup as an HTTP Event Handler to block SP Access. It can be found here: No SPD HTTP Event Handler.

What is your response to the news? Excited, terrified? Post a comment!

Buy versus Build

A discussion broke out on the MSDN/TechNet SharePoint Forums this week that started to approach the subject of build versus buy. It is something I have had to put a fair amount of thought to in the past so I decided it might make for an interesting blog post.

As a developer, I enjoy developing. It is always fun to dig into code and solve a problem or fill a need. Unfortunately I don’t get nearly as much time to develop as I used to or would like. It ends up being something I do between meetings, on weekends, or in support of a project when the other developers are not available. As I’ve moved through the roles of developer, team leader, architect / program manager I have had to look at things from different angles including that of what is best for the company or the users the solution is being deployed for. Sometimes those personal goals and enjoyment have to be set aside in support of the company’s and users’ best interest.

One of the main trends of computing over the past 10+ years is the move towards interchangeable components, services, etc that can be stitched together offering reuse and decreasing the total cost of managing systems. SharePoint is a great example of this as a platform that has a rich market of third-party vendors. There are 100s of available solutions, web parts, etc that are publically available.

Here are some considerations when evaluating whether to Buy or Build solutions.

Requirements – Is there a solution available that meets the requirements? Is there something close enough to consider as an option? If not, and its needed then its clear you would have to develop it.

Initial level of effort – Do you, or does somebody on the team have the skills and know how to develop the solution or is this a learning opportunity? How long do you expect it to take? If it is full of unknowns or if the projected cost based on a standard rate ($50 an hour?) comes to 80% or more of a commercially available solution it probably isn’t something that should be custom built.

Are there other things that are a better use of your time? The last few organizations I’ve worked with I’ve had a running backlog of projects averaging two years. It is normally easier to purchase components than it is to add to the headcount. Purchasing components or solutions makes it that much easier to deliver value quickly.

Ongoing maintenance and support – Do you or does the group have the time to support the solution going forward? You may have time now, but if you squeeze it in what happens when they come back for changes or you need to upgrade? Will you have time to work on it? You can rely on the vendor for this in most cases if you purchase support for the solution.

On the flipside, make sure you take into account the vendor’s stability and history and make sure that they will support the solution going forward and/or still be around. I have made the mistake of purchasing a solution from one company that sold me a dead-end product that was replaced.

Quality / Grade – Do you, or your team have the skills to meet the needed quality and grade of the solution? In most cases the commercially available solution has a team supporting the development effort to include qualified quality assurance professionals.

Budget – Do you have funds available for the purchase. In some cases there just is not money available, we are in a recession after all, but smart businesses will find the funds if the solution does add value and save time. Mature organizations probably understand this a little better, and therefore tend to have larger budgets to support the purchase of technology.

Summary
By taking these considerations into account it will help you make decisions that add value to the organization and its end users.

SharePoint Customization Policies and Change Control

This post will cover different forms of customization, discuss the need for IT policies that support customization, and then provide a recommendation for how to manage the customization through change control processes.

What is considered customization?
There are different types of customizations and different ways to apply them. They can include custom styles, MasterPages, Web Parts, Custom Forms, Site Definition or even applications built on top of the API.

Bad customizations are applied manually by adding to or altering system files on the server. These changes are not saved into the configuration database which can cause problems when applying system patches or upgrades. It can also make it much more difficult to add an additional server to the farm as those changes have to be manually applied again. Therefore this should never be done in a production environment.

Well built customizations are deployed using SharePoint’s robust deployment framework for Web Parts and Solutions. This not only produces repeatable results, but it also helps keep multi-server farms in sync and allows those customizations to be pushed out automatically to new servers joined to the farm. This method is also much less likely to produce problems when applying patches, updates or even upgrades.


SharePoint Success without Customizations?

While I believe strongly that there is a lot of value in the base solution, I think that SharePoint is set apart by the expandability and integration options. This is what can take it from an ad-hoc workgroup solution to an enterprise platform.

Too many IT shops have taken a No Customization stance when it comes to Enterprise Software. They will quote ballooning implementation costs, reliability of the changes or the difficulty that exists in performing normal version upgrades. Many of these are valid issues to some degree with packaged software, but it is not an irrefutable law. SharePoint is a platform that is intended to be molded to meet an organization’s needs, and customizing it is not the same as rewriting core sections of an ERP system.

In more than on instance I’ve seen SharePoint workflow projects move forward with the decision that no “code” can be written, which means they cannot use Visual Studio or create custom actions. The alternative is for them to use SharePoint Designer to create those workflows. While that may be a good idea for small or simple workflows, there are limitations, but even worse there is no reusability in their work. If something similar is needed somewhere else it has to be recreated.

By making a unilateral decision that no customizations can be made, you are handicapping the system and limiting the value it can deliver. Business and IT leaders need to consider this before making any policy changes.

What about Change Control?
In organizations where there is a Change Control policy in place, it is important to categorize the types of changes. I would advocate grouping changes into the following groups Content and Site Configuration, Packaged Code, and System Level Changes.
Content and Site Configuration – This includes using the toolset to add and update content in lists and libraries along with the creation and design of Sites, Lists, and Libraries. These tasks should not require approval.

Packaged Code – This includes the installation of custom or third party web parts, solutions, workflow actions and templates. Since these packages can possibly cause harm, and should be part of the system’s documentation, it should pass through the Change Control process.

System Level Changes – This includes adding an additional server to the farm, changing a servers’ role, reconfiguring personalization features or rebuilding the Shared Service Provider. These changes can possibly have a huge impact on the entire system. It is important to capture the details of those changes in the documentation, and also make sure that all stakeholders are aware of the changes being made.

Planning for Separate Site Collections

When planning out the site structure of a new SharePoint system, here are five things I take into consideration. Taking these into account during your planning phase will hopefully reduce the amount of rework needed as your system evolves.

Amount of data

If you are expecting a large data set, perhaps you are scanning all supplier invoices and using SharePoint for Content Management, its important to consider the size of a Site Collection and the underlying Content Database from an Administration standpoint. Larger Site Collections and Content DBs require more care and attention along with a more advanced skill set. There have been a number of discussions on what the guidelines are, but I aim to keep Content DBs under 40Gb unless there is a real exception. In this case, the size of the data over rules any of the other answers.

For site collections I expect to grow large, I set them up in a dedicated Content DB right from the start. This saves the trouble having to move it to a different content DB later which can take some time with large sites.

Type and Purpose of the Sites

In a small to mid-sized organization I typically treat sites that support Intranet or department level collaboration a little different than cross-functional or project type sites. Its easy to define the groups around the functional areas and you can reuse those groups in other sites where there is overlap.

In larger organizations sites typically require more isolation. There may be a some interaction between the groups, but not within divisions. In this case the Site collections can be structured to support the organizational boundaries.

Groups Definition and Membership

Groups are defined within the site collection container. If you setup a group called “Management” in Site Collection A, it wouldn’t be available to Site Collection B unless its setup separately. It may not sound like a big deal, but it gets very tedious when you have to manage the same group in multiple places. To make matters worse administrators often take for granted who is in the group based on the name. When setting Site Permissions a group’s members is not directly visible.


Navigation

WSS and MOSS have some good out of the box navigation systems. They are limited though when it comes to trying to tie together multiple Site Collections. There are solutions like defining custom providers but then you are introducing sophisticated customizations that not every company can support. A last ditch option is to manually link to sites and resources but then everything becomes much more difficult to manage.

If it is important to have a consistent horizontal navigation scheme, look to keep as much as possible within a limited number of site collections.

Aggregating or Reusing Data

One of SharePoint’s greatest values is in its ability to support syndication and aggregation of content to deliver it where the users need it. You can aggregate the content using tools like the Content Query Web Part or DataViews. These techniques get a little more complicated when content is in different site collections. Custom code or third party tools are then required to accomplish bring things together.

Feedback?
Agree? Disagree? Let me know, I would love to hear your feedback.

%d bloggers like this: