Get More... Experience

Note2: Only works with MOSS 2007 sorry as you WSS guys do not have audiences targeting

This is my small contribution to the SharePoint world. It is a web part that once added to a web part page, allows you to customise the display by adding JavaScript to selectively hide controls on the page . Ever needed to hide a field from display/edit for a certain audience? Well here is a way do it without requiring SharePoint Designer and having to break a page from it’s site definition (unghosting).

Before and after shots below (look ma - no top button!)

 

To fully understand what is being done here, I suggest you read my series of articles on the use of JavaScript in SharePoint. Part 3 in particular will show you how to safely add this web part to pages with editing disabled (NewForm.aspx, EditForm.aspx and DispForm.aspx)

The full series can be found here: Part 1, Part 2, Part 3, Part 4, Part 5 and Part 6.

Kudos to Jeremy Thake for feedback and some code contribution. Despite being seriously metrosexual, he is otherwise otherwise very cool :-P.

Now two important warnings:

Warning 1: This is an alpha quality release and I may never touch it again So you very likely *will* break it. If there is enough interest, I am happy to pop it on codeplex

Warning 2: This web part should NOT be considered as a security measure and thus used in any security sensitive scenario (such as an extranet or WCM site). JavaScript by its very nature can be trivially interfered with and thus other methods (server side) should be employed in these scenarios to prevent interference at the browser.

You can download by reading the disclaimer and clicking the button below..

THIS CODE IS PROVIDED UNDER THIS LICENSE ON AN “AS IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER

Use at your own risk!

To install perform the following commands

1. stsadm.exe” -o addsolution -filename CleverWorkAroundsHideFields.wsp
2. stsadm.exe” -o execadmsvcjobs
3. stsadm.exe” -o deploysolution -name CleverWorkAroundsHideFields.wsp -immediate -allowgacdeployment -allcontenturls
4. stsadm.exe” -o execadmsvcjobs

To remove/reinstall perform the following commands

1. stsadm.exe” -o retractsolution -name CleverWorkAroundsHideFields.wsp -immediate -allcontenturls
2. stsadm.exe” -o execadmsvcjobs
3. stsadm.exe” -o deletesolution -name CleverWorkAroundsHideFields.wsp
4. stsadm.exe” -o execadmsvcjobs
5. stsadm.exe” -o addsolution -filename CleverWorkAroundsHideFields.wsp
6. stsadm.exe” -o execadmsvcjobs
7. stsadm.exe” -o deploysolution -name CleverWorkAroundsHideFields.wsp -immediate -allowgacdeployment -allcontenturls
8. stsadm.exe” -o execadmsvcjobs

Development Environment

SharePoint development environment configuration depends on the processes, type of engagements and type of work. The most popular solution that addresses the development scenarios is using local SharePoint farm, separated from the production servers, with the single installations of the SharePoint server on the development boxes. This provides isolation for builds, tests, and debugging across different teams, projects and production environments. The local environment is mostly isolated by development box and is installed on the host server or on virtual server. The following procedure is an overview of the steps that are required to create a typical SharePoint development environment.

Development Box installation

• Use Windows Server, Visual Studio, and SQL Server. Windows Server 2008, VS 2008 and .NET 3.5, SQL 2008, with TFS 2008 is officially supported environment for SharePoint development. Advantage of Windows 2008 is that it is fast in virtualized environments.
• Install SharePoint on development boxes and prefer not to connect to existed farm instances used on other stages. Development environment should stay apart, to develop and tests in isolated environment.

Chose development tools

There are varieties of tools that can make development fast and easy - from commercial to open source and Microsoft products.

Microsoft recommends to use “Visual Studio extensions for Windows SharePoint Services” (VSeWSS), which simplify code-up solutions for SharePoint (e.g. Web Parts, List Definitions, Site Definitions, etc) via UI and allows reverse-engineering existed site to extract definitions for SharePoint entities.

The disadvantages of VSeWSS are:

1) not intuitive for beginners;
2) doesn’t provide usability to change all properties of the features, and other SharePoint items easily
3) Cannot use VSeWSS projects without VSeWSS extension.

Others 3-rd party tools, which simplify development, are:

1. Management Tools

• SharePoint Spy (http://www.echotechnology.com)
• SharePoint Manager (http://www.codeplex.com/spm)
• SharePoint Analyser (http://community.bamboosolutions.com)

These tools help to manage services of SharePoint farm and get detailed information about configuration settings.

For example, screenshots of SharePoint Analyzer (left) and SharePointSpy (right)

2. Visual Studio Tools

• STSDev to create project files (http://www.codeplex.com/stsdev)
• SPSource to get site sources (http://www.codeplex.com/spsource)

These tools create Visual Studio projects with the SharePoint 12-hive structure, and provide build settings to build/deploy/retract WSP packages directly from IDE. STSDev is the best tools to create a variety of projects - from simple features and Web Parts to Custom Workflow projects:

3. Development Tools

• TypeMock Isolator - Writing test for the SharePoint is a hard task for the developers, due to number of internal, sealed and private classes that are used across all SharePoint objects. ”TypeMock Isolator” is the only unit-testing and mocking framework for SharePoint, which provide ability to fake recursively, and simulate collection easily.
• SPDisposeCheck - tool to check assemblies that use the SharePoint API to build the better code. It provides assistance in correctly disposing of certain SharePoint objects to help following the best practice.

4. Other Tools

• U2U CAML Builder - editor for CAML queries (http://www.u2u.net)
• SharePoint Feature - set of different development and debugging plugins (http://www.codeplex.com/features)

Such tools give your additional flexibility in everyday development stuff, providing different editors, log viewers and analysers to make SharePoint development easier and faster.

Setup Deployment environment

Configure Continuous Integration (CI) system to build SharePoint solution, compile output to WSP packages, prepare deployment scripts and deploy WSP to Test Environment. Team Foundation Server (TFS) is one of the recommended tool for this task. There are several articles describing how to adopt SharePoint solution for CI, setup builds and configure TFS Deployer to deploy SharePoint packages across different environments:
http://www.azsharepointpros.com/ShareAndEnjoy/Lists/Posts/Post.aspx?ID=10

As to SharePoint Visual Studio Templates, CodePlex has a “SPTemplateLand” project that provides “12-hive” structure for SharePoint projects and deployments.
This solution was slightly modified by Microsoft SharePoint Consulting Services guys to have single deployment package for multiple projects and support packaging additional SharePoint Artefacts (site definitions, root files). This project is published there http://blogs.msdn.com/gderun/archive/2008/01/11/sharepoint-visual-studio-project-and-deployment-templates.aspx

Configure testing environment

The following diagram depicts the most common development environment, which is recommended by “SharePoint Guidance patterns & practices” team.

1. Stand-alone SharePoint environment for development, unit testing and debugging of SharePoint project. Runs continuous integration and builds verification tests before deploying the SharePoint solutions to the test environment.
2. Source Control/Build Server to build SharePoint packages (WSP) and to deploy solution to test environment.
3. The test environment performs user acceptance testing, manual functional testing, automated functional testing, system testing, security testing, and performance testing. After the solution meets production requirements, the SharePoint solutions are deployed to the staging environment.
4. The Staging server uses to test the “production-ready” solution in an environment that closely resembles the production environment. The purpose of this environment is to identify any potential deployment issues. Although the Staging environment is optional for smaller applications where deployment failures are not critical

The staging environment represents the target production environment as closely as possible from the perspective of topology (for example, the server farm and database structure) and components (for example, the inclusion of the Microsoft Active Directory service and load balancing, where applicable).

---

In the next part we will describe the backup strategy to provide disaster recovery for SharePoint Farm

Overview

Planning and installing SharePoint Farm across enterprise network is not a trivial task. SharePoint is rarely installed in an isolated environment, and usually it interferes with the organization strategy and existing infrastructure. Many factors may affect farm design, performance, scalability and redundancy - from hardware devices in organization network, to network topology. As a result, leveraging and finding compromises among those factors helps to build consistent, reliable and flexible environment.
There are several whitepapers on the Microsoft TechNet portal describing requirements for SharePoint Farm, but most of them are either written without taking into account infrastructure scope or filled with irrelevant information that navigate the reader away from the problem scope.

In this document you will find the configuration recommendations regarding different SharePoint areas. All information is represented in the set of recommendations about different actions you need to undertake or pay additional attention when you install and configure your SharePoint environment. We tried to structure all section to follow the natural flow of SharePoint installation from the scratch - from pre-installing analysis requirements to post deployment actions.

We plan several whitepapers in our “Best Practices” series, and we are interested which topis you would like to see in our next SharePoint publications. Please send us your comments and suggestions via this form.

Introduction

Organizations adopting SharePoint face a variety of tasks - from planning, strategy, infrastructure and architecture design, UI Design, migration, and to development. All these tasks imply flexible infrastructural baseline before actual work starts. However, in reality we face the outdated environment and misconfigured farms that are not ready to implement new requirements. In such cases, baseline architecture becomes foundation stone of all SharePoint projects.
Why would we care about infrastructure and not about something else, for example development? Fixing infrastructure errors is very expensive task and leads into significant changes across SharePoint farm. For example, Index Role assigned to the wrong server and incorrectly configured Search can lead to performance and redundancy issues that might require up to 3 days fix. Development errors are not so expensive and can be fixed relatively quickly, but sometime such errors, eventually become infrastructure errors that lead to changes in infrastructure design.

“Architectural Planning”

Plan your farm and network communications before starting actual installation. The first thing to start is designing SharePoint architecture across corporate network. This includes understanding network structure, examining network devices and choosing the right SharePoint topology to fit the existing infrastructure and new requirements.

Examine corporate network

Start from description of the existing network design, location of all applications and system servers. Microsoft Visio 2007 and “Network Diagram” template is a good instrument for this task.

Record the location and information of corporate system servers, like Domain Controllers, File Servers, Mail Servers, Application and others. Dont’ forget about network services - firewalls, proxies, and etc. For example, locations of ISA Servers across corporate network - IP address, list of open ports and the administrative user.

The best way to maintain “Network Diagram” document is to update the single diagram that covers topology of all domains and how they are connected. The following diagram demonstrates the Visio document descibing the servers and devices across organization.

This diagram will give a holistic view of the existing topology and ensure quick access to information across different domains.

Examine network devices

All network devices in the topology play a vital role of how SharePoint performs and interacts among different servers. Information about locations and settings of all routers, switches, and accelerators become very important in planning server locations. For example, location of different WAN and XML accelerators across network affects SharePoint server organization and configuration.

Presence of different network devices affects the connection bandwidth and latency between farm’s servers, and thereby, affects the choice of appropriate SharePoint Farm topology. Network Load Balancers (NLB), routers and switches will affect how fast network response, therefore the farm should be designed with the least impact of these devices.

Refer to the following links for the detailed information about WAN accelerators, NLB and other network devices across SharePoint farms:

1. http://technet.microsoft.com/en-us/library/cc263099.aspx
2. http://blogs.msdn.com/joelo/archive/2008/01/17/global-sharepoint-deployment-partner-solutions.aspx
3. http://blogs.msdn.com/joelo/archive/2007/01/05/nlb-network-load-balancing-and-sharepoint-troubleshooting-and-configuration-tips.aspx

Network administrator is a friend

The IT administrator is the person who should participate in farm configuration from the very beginning. This person will be responsible for the configuration of all network servers and devices across corporate network.

Most of the SharePoint Farm topologies cross the bounds of domains and from the very beginning specific protocols and ports must be open. The best way to maintain current situation is to have a separate document, shared with administrator, with the description of protocols and ports to open across network services.

Detailed information about system accounts and list of ports is available in the following articles:

• Plan for administrative and service accounts (Office SharePoint Server) http://technet.microsoft.com/en-us/library/cc263445.aspx
• Office SharePoint Server security account requirements http://go.microsoft.com/fwlink/?LinkID=92883&clcid=0×409

Measure network latency

Network response time is one of the important factors that can affect SharePoint farm design. Ideally, you need to measure the latency between SharePoint servers and users in order to reorganize servers according the smallest response time.

Network latency is the key point to determine which of the proposed scenarios to implement in the current SharePoint deployment. (Latency is the time required for a packet to travel from one point on a network to another).

Use the Ping tool (ping.exe) to measure latency for:

• users - from the client computer to the Web server on the server farm;
• data centres that host servers of the same farm - from a Web server in the remote data centre to the database server in the primary data centre

Do not forget to divide the round-trip result by two, because all measures are one way only, not round-trip.

Compare results to the data below, and adopt environment to have latency lower those values.

Number of users	Concurrent users (10%)	Central Solution	Distributed solution
100-5,000	10-500	Bandwidth:   3+ Mbps (dual T1)Latency:   < 100 ms	Bandwidth:   1.5 Mbps (T1)Latency:   <100 ms
10,000	1,000	Bandwidth:     3+ Mbps (dual T1)Latency:   <250 ms	Bandwidth:   1.5 Mbps (T1)Latency:   <500 ms
100,000	10,000	Bandwidth:   3+ Mbps (dual T1)Latency:   < 250 ms	Bandwidth:   1.5 Mbps (T1)Latency:   <500 ms

The critical bandwidth for any SharePoint farms is 1.5 Mbps (T1) with 500ms latency. Overstepping these values will increase the page-load times dramatically, in 4 times at least. Refer to the diagrams in the “Plan for bandwidth Requirements” document, for more details about the bandwidth and latency results under different conditions.

Available network bandwidth and latency influences geographic deployments significantly. Data transfers across WAN links that span multiple cities, states, provinces, countries, or continents requires really fast lines to provide adequate response time, so design such topologies thoroughly.

More details for bandwidth requirements available in the following article http://technet.microsoft.com/en-us/library/cc262952.aspx

Become familiar with SharePoint farm communications

Before discussing servers’ redundancy and farm topologies let us review farm servers and how they communicate with each other. The following picture from from “Planning an Extranet Environment for Office SharePoint Server” TechNet article illustrates the communication channels within a server farm and which servers handle client’s request.

When a user issues a query, the query is sent to a Web server. The Web server communicates with the query server to build a list of results, and then communicates with the computer running Microsoft SQL Server to extend the list of results with summarization text, URLs, and security trimming. In parallel, the Web Server gets page data from SQL Server and renders them on fly. This diagram will help in understanding which roles to use on farm servers.

Plan a baseline topology

Analyse the existing infrastructure and plan a SharePoint topology for redundancy. The term redundancy is often misinterpreted to be synonymous with availability.

Redundancy refers to the use of multiple servers in a load-balanced environment for any of several purposes, such as to improve farm performance, to scale out to accommodate additional users, and to improve availability.
Availability is a more specialized concept that refers to a multiple-server environment that is designed to accept connections and operate normally even when one or more of the servers in the farm are not operational. Therefore, availability implies redundancy.

There are several different topologies - from three to six servers in farm, which can be used as a baseline. Which one to choose depends on the level of redundancy and available hardware. Not all clients can afford topology with six or ten servers in farm due to budget limitation or data centre capabilities. Finding the compromise between numbers of servers, type of hosting and servers’ roles become critical task, because this choice will affect performance and extensibility of the SharePoint farm for several years ahead.

Three Servers Farm

The minimum availability for the farm with few servers can be achieved with “3-servers farm” topology. In the current topology Web and Application Servers locate together on the one box and the database is on another box. The remaining, third, server gives a choice of which server role make redundant - Web server role or the database server role.

The farm with the two Web Servers provides redundancy of the Web and Application roles, improving the overall performance. A drawback of this design is that your data is not redundant (left farm). In other case, farm with two Database Servers (cluster) provides data redundancy, increasing availability of critical data, but users might suffer from temporary loss of access, when Web Server unavailable (right farm).

The “3-servers farm” is one of the most questionable farms in terms of redundancy and performance. This limitation in the number of servers cannot provide redundancy of Query Server and high performance at the same time.

Redundancy can be achieved with Query Roles on both Web App servers. In this case, Database Server is the only place for Index Role, but this will hinder the overall performance. The Index Role is very CPU and HDD consuming role and that is why database servers are not very optimal place for this role. Alternative solution is to assign Index Role to the Web Server with the Query Role, but this will not work effectively, because in this case, index will not be propagated to another Query Server in farm.

If performance is one of the priorities then consider using Query Server and Index Server Roles on different Web Application Servers. This is flexible design in terms of extensibility, because with the new servers in farm changing roles of Index and Query servers is not required.

Interestingly, a TechNet article (http://is.gd/8QbS, page 26) explains, that a Query Server can’t be used with Web Applications server for 3-servers farm. The reality is that, Web App and Query Role together are super common, more common than not (one of the reasons is that Query Server doesn’t use Network-Load Balancer - it uses its own algorithm).  What they actually mean in the TechNet article is that having the  Index on database server is not at all a recommended solution.

Four Servers Farm

Additional, forth server will add redundancy either for Data Server or for Web Server. However, it does not help much with performance. Current topology suffers from the same “3-servers farm” drawbacks - no place for Index Server with Query Role redundancy.

Five+ Servers Farm

The most common and highly available server farm topology is “5+ servers farm”, the farm with the middle tier server.

This middle tier server solves all issues of three and four servers topology by providing the dedicated tier for Index and Application roles. Additional servers in farm will extend middle tier, by assigning new roles to those servers - Excel Calculation Services Role, and Microsoft Office Project Server 2007 Role.

The following table summarize farm topology:

Farm Servers	Performance	Redundancy
3 - 4	Index on WFE with Query on another boxApp Roles on WFE	Index on Database, with Query on WFEApp Roles on WFE
5	App Roles on Middle TierDedicated Index Server on Middle Tier	App Roles on WFEDedicated Index Server on Middle Tier
6	Dedicated Web Server for Crawling, outside NLBDedicated Index Server on Middle Tier	App Roles on Middle Tier in NLBDedicated Index Server on Middle Tier

To optimize the overall performance of five and more servers SharePoint Farm, configure a dedicated Web Server for crawling content, especially when crawling a server farm that contains more than 500 gigabytes (GB) of content or crawling content over the WAN. To ensure that user requests are not affected by content crawling, remove the dedicated Web server from the network load balancing rotation. This is especially important in global environments in which the off-peak hours of a regional farm (when crawl jobs are likely to be schedule) coincide with the peak hours of the central farm.

Plan extranet topology

Choose the topology based on requirements for external users. This topology will provide a basis of network extensibility for applications servers and communications between them.

The simplest topology is “Edge firewall topology”, which is represented by following diagram, from TechNet article.

This topology applicable for the small farms, when there is no need to separate internal services from corporate network and secure communications between server farms. All remote users are separated from farm by ISA server which plays a role of remote proxy.

For the big farms, when security of communications is a priority, the recommended topology is “Back-to-back perimeter topology”. This is very flexible and adaptable topology for network changes.

The main advantage of this topology is that it isolates the server farm in a separate perimeter network. Layers logically separate all servers and communications are under control - any security damages affect only specific layer, not the entire farm. External user access is isolated to the perimeter network and users can be isolated in different AD for remote and corporate access.

There are some other extranet topology variations, but mostly all of them are based on “Back-to-back perimeter topology” with some modification.

Detailed information about farm topologies can be found in the following documents:

1. Best practices for My Sites: http://technet.microsoft.com/en-us/library/cc262706.aspx
2. Best practices for team collaboration sites: http://technet.microsoft.com/en-us/library/cc850694.aspx
3. Planning an Extranet Environment for Office SharePoint Server: http://technet.microsoft.com/en-us/library/cc262400.aspx

“Logical Planning”

Plan site collections

Plan number of site collections and sub sites in advance - content, location, security. Start with the single site collections and several sub sites rather then creating several site collections, and try to avoid new site collection if there are no requirements for this. The reason of such structure is that each new site collection works as a new application, with isolated scope to features, templates and search. Maintaining such structure is much easier than several site collections.

Organize site collection across several content databases

Do not end up with one big content database, because data optimisation will cause troubles in this case. For the small and development environments, single content database might be a preferable choice. However, for the large farms create several content databases and organize site collections among them. Having several content databases with sites helps to address the following:

• Keep content database size <100 GB, otherwise it could hinder performance (MS recommendation)
• Data usage optimization.
• Simplify farm backup and restoration.
• Flexibility for Disaster Recovery (DR) strategies.

More details about site collections in several content databases available in the following blog post: http://msmvps.com/blogs/laflour/archive/2008/10/14/tips-to-create-a-site-collection-in-new-content-database.aspx

Script actions

Prefer to script installation and SharePoint Farm configuration actions: setting roles, creating web sites and site collections, etc. Configuring successful farm from the first attempt has a change to fail due to complexity of SharePoint. Running scripts to repeat all actions will save time when something went wrong and new server installation is required.

---

In the next part we will review the actual SharePoint installation and the basic farm configuration.