1. Synopsis.....................................................................................................................................1
Farm Model ................................................................................................................................1
Development and Testing Farms ..............................................................................................2
Development Farm ....................................................................................................................2
Sand-Pit Farm............................................................................................................................3
TEST Farm.................................................................................................................................3
Pre-Prod Farm ...........................................................................................................................4
Production Farm.........................................................................................................................4
Business Model..........................................................................................................................5
Business Hub.............................................................................................................................5
The Service Centre....................................................................................................................5
Teams ........................................................................................................................................6
Archive Record Centre...............................................................................................................6
Team Collaboration....................................................................................................................7
Synopsis
SharePoint has been introduced to the business units as a possible replacement to the file
system storage and existing document management systems.
During the development and testing stages we have recommended that the SharePoint
architecture uses four additional farms which will minimise disruption to the PRODUCTION
SharePoint environment. This also facilitates the safe migration of data between farms and
allows a robust change management mechanism; i.e. a development environment which
supports a single multi developer development platform, a Sand-Pit environment for testing
ideas and two staging environments to test the build and installations / configuration which
are detailed below as the Farm Model.
Additionally we have introduced a new business concept which separates the SharePoint
entities into separate administrative areas and allows non SharePoint engineers to focus and
learn individual SharePoint tasks. Administrators are required to familiarise themselves with
the relevant administrative configurations according to their role which are detailed as the
Business Model.
Farm Model
The Server Configurations consists of five separate Farms, the Analysis and staging
environments rely on a single SQL Server and each Farm has its own SQL Instance. The
PRODUCTION environment uses of a mirrored SQL server in each data centre.

2. ** Please note the Server names and instances act as only a guide and do not reflect the environment
server names
Developmentand TestingFarms
To test notification, it is recommended that email redirection is configured on the emails that
originate from the analysis and staging environments to an alternative email address. This
allows developers and administrators to use the LIVE active directory environment and test /
confirm email behaviour using actual user names and distribution groups. This way you can
confirm the correct notification / delivery by investigating the alternative email account
emails.
This system also uses the production Active Directory environment which requires that the
appropriate user rights have been assigned and correctly configured for use with
SharePoint. To avoid litigation the correct SharePoint governance model and change
management procedures must be in place as not to expose confidential and sensitive test
data especially when demonstrating the functional and business layers in the test systems.
** Please note. If you are copying PRODUCTION or confidential data outside the security of the LIVE
SharePoint environment you are responsible for the protection of that data. Care must be taken to
assign the correct permissions to the data once it has been copied. Also remember how permissions
cascade down and remember the all too powerful Site Collection and Farm Administrator accounts
which can easily manipulate and take ownership of libraries containing sensitive data. Also bear in
mind their partially anonymous nature when studying the audit trail and information logs. Remember
that developers and administrators my know the test, service and farm analysis and staging
passwords so always seek approval and written consent from the site sponsor. For added security
provide relevant documentation on testing and confirming the data is protected. If in doubt, do not
copy the data or assume the sponsor will take full responsibility for your actions, remember they rely
on your professional judgement.
Development Farm
The development farm is purely for developing and testing applications, this area should be
regarded as an area for developers and the first stage of testing third party solutions. This

3. server has Visual Studio installed and Terminal Services to allow a small team of developers
to work simultaneously (problems may arise with IIS resets or Server Reboots). This area
should also be regarded as an unstable environment as developers are renowned for
installing third party tools and DLL’s. The developers should also save their projects and files
to an alternative location as this area is not part of the backup strategy. Documentation
should include on how to reinstall this environment to the original installation which should
be done at regular intervals. The development farm should not be used for user training and
PRODUCTION data should not be copied to the development environment.
Sand-Pit Farm
The Sand-Pit’s primary purpose is to test ideas and the initial design templates constructed
using categories and taxonomies which have been derived from the requirements gathering.
The sponsors, testers and reviewers are initially the primary audience for a Team Site
Collection so the look and feel should reflect the PRODUCTIONsite. Obviously, there will be
subtle differences as the requirements gathering changes are played out, also consider the
impact to your fellow Team Site Collection Owners to incorrect-configurations which could
render the environment unstable.
This is also the first stage testing area for developer solutions which provides the developer
with an opportunity to install and activate their solution in a new SharePoint environment.
This environment may not have all the required support files which normally reside in the
development environment and this is where the developer can confront the challenges when
getting a solution to work outside the developer environment. This should also be considered
as an unstable environment and not to be used for training. If the Sand-pit is used for
meetings, demonstrations or initial testing they should be aware that other departments may
need to be notified and the system reserved / locked for the duration of the meeting,
demonstration or test. PRODUCTION data should never reside in the Sand-Pit environment
and if bulk data needs to be tested then this should be done using anonymous entries
generated via script or programmatically. This system is not part of the backup strategies.
TEST Farm
The TEST Environment is the first step to staging and this sever partially reflects the LIVE
system i.e. two Web Front Ends, two Application Servers and a Single SQL named instance.
On completion of the requirements gathering which was carried out on the Sand-Pit, the
teams can now recreate their accepted designs in TEST. This is a staging environment
which means that everything built and installed in TEST will eventually move to the
PRODUCTION environment. If it is not destined for the PRODUCTIONenvironment, do not
put it into TEST, the only caveat to this is; Developer Solutions may not configure correctly in
a Multi-Server environment which may present additional challenges to the installation of
web parts or solutions. When solutions are installed on TEST, to avoid disruption the
environment must be reserved / locked as multiple teams may be working on the system,
also backups must be in place in order to restore this system to its original state. This
system must be regarded as a LIVE environment with the same redundancy and backup
strategies as the production environment as this will be used for testing and training. Teams
may import PRODUCTIONdata to this area for testing and training but the PRODUCTION
data must be governed by the appropriate user rights and Change Control procedures and
care must be taken as not to expose PRODUCTIONor confidential data. This data must be
removed once the testing / training has completed. TEST is also used by infrastructure

4. engineers to employ new SharePoint configurations and these changes may be aggressive
so care must be taken to notify other uses and reserve the system for their sole use during
these changes, also the change must be reversible in case problems arise.
Pre-Prod Farm
The Pre-Prod environment is the second and final stage and this environment is used to test
how we move the changes from TEST to PRODUCTION i.e. the installation. This is a single
server environment so any developer challenges which may manifest themselves in multi-
server environments must be resolved on TEST and the installation tested on TEST and
Pre-Prod. If additional steps are required the steps must be fully tested from start to finish,
the preferred method is either by a activating a solution or running Power Shell commands
and if there are manual steps they must be fully documented. Steps must also be
documented which allows engineers or testers to verify a successful installation or
configuration. This environment may require testing with PRODUCTION data so the
database should be copied to the Pre-Prod farm from the PRODUCTION environment. Once
the testing of PRODUCTION data has completed the data must be removed and the original
database reinstated. Again, care must be taken not to expose PRODUCTION and
confidential information by protecting it with the appropriate User permissions.
** Several discussions have taken place regarding the server configuration of TEST and Pre-Prod
especially where to target the full or single server configurations, each with their advantages,
disadvantages and cost implications. Remember that each server must have the appropriate
SharePoint licence, SQL server licences and Licences for any additional software, albeit solutions,
third party DLL’s or web parts etc. MSDN, Developer Subscriptions or Trail Versions generally cannot
be used for this purpose and care must be taken to make sure all Software has been correctly
licensed and purchased, it is the responsibility of the individual who configures and installs the
operating system, application software or third party software to make sure the appropriate licensing
requirements are in place.
Production Farm
The Production environment is the LIVE environment and all changes (no matter how trivial)
must follow the required change management procedures, the scripts which have been
tested on Pre-Prod will require editing to reflect the appropriate environment, i.e. Server
Name, Application URL, Database Server, Data Base name etc. (this must be reviewed prior
to running the scripts by an additional engineer). The identical procedure developed on Pre-
Prod must be replicated to the LIVE environment and all verification steps must be checked
to confirm the successful change or installation to the LIVE environment.
** Please note that rolling back a SharePoint farm to a previous configuration should not be taken
lightly, a full rollback is a complex operation and will require the full co-operation of the IT support
team, especially if the environment has mixed physical and virtual server configurations and
SharePoint shares the SQL server with other applications. This will also require an experienced SQL
server administrator who is familiar with the various SharePoint databases.

5. BusinessModel
The business model has been divided into separate administrative areas
Business Hub
Planning is essential when requesting a team site in the SharePoint environment and this
journey starts with the business team. The business identifies the categories and
governance as several types of taxonomies; these taxonomies are required to define
structures and vocabularies that are used primarily for tagging, workflow actions, policies,
search and navigation. It is recommended that the business administrators are familiar with
mind mapping techniques and working with large taxonomies, i.e. the Local Government
Classification Scheme. The business team should also familiarise themselves with the
content type hub which provides the core configuration for lists and libraries in the form of
columns and content types. Business hub administrators should receive training to the level
of SharePoint power users.
The Service Centre
The Service Centre provides crucial services to SharePoint and this arena is very different
from the standard SharePoint interface. It is recommended that Service Centre
administrators are familiar with infrastructure models and well versed with networking
protocols, internet information servers, active directory management, group management,
web protocols, SQL server administration and server administration etc.
Service Centre administration covers (Standard Edition)
 Business Data Connectivity service
 Managed Metadata service
 Search service

6.  Secure Store Service
 State service
 Usage and Health Data Collection service
 User Profile service
 Web Analytics service
 Word Automation Service
An infrastructure engineer who is tasked with the day to day running of a complex windows
network should find the services configuration relatively straightforward, to maintain these,
services engineers should have: a good understanding of SharePoint central administration,
SharePoint configuration documentation and well defined service request and change
management procedures.
Teams
Teams site collections are the main area for collaboration and each team site collection
consists of three sub sites; the root site “Home” which contains documents pertaining to the
Team, “Operations” which is used for the day to day running of the Teams business and
“Support” which allows collaboration within the Team staff. The building blocks for Teams
come from the initial Site Template which contains the standard Sites and the addition of
Libraries which are published using the Content Type Hub which has been populated during
the requirements gathering stage.
The Libraries developed for use in the Team Sites are initially created in the Sand-Pit area
and once this has been signed off, they are moved to the Staging Servers where specialised
scripts can automatically configure the Staging Servers using templates which have been
created in Sand-Pit.
The Infrastructure Support team should be familiar with the SharePoint web interface,
understand basic XML to confirm the Script Variable and understand concise documentation
and change request procedures to confirm that the scripts executed correctly
Archive Record Centre
The archive follows the standard record centre / archive strategy were document libraries
are provided with a global workflow “Send to Archive” which allows the user to manually
send the chosen file to the archive via a workflow. Once completed the file or document set
is copied to the drop off library and then routed to the defined Storage Location within the
archive site collection. The “Send to Archive” workflow solves one of the main areas of
confusion when a file is not routed due to the lack of a rule or required property value and
the records remain in the drop off location.
The “Send to Archive” workflow makes the following decisions
 Do the archives / record centres exist?
 Have rules been defined?
 Will the record properties allow a successful route?

7. If the following has not been met then the user is notified that the move was unsuccessful
and a Contact the Administrator message is displayed to create a rule or check All
Conditions have been configured correctly to allow a successful route.
On the successful completion the file or document set (and its contents) are undeclared as a
record and moved to the Recycle Bin. This also allows the return of the file to its original
location by the owner (in case it has been deleted in error) but note that in this instance it will
reside in two locations so it is important the Record Centre administrator is notified.
The Record Centre Manager should be familiar with SharePoint and how to manage the
Record Centre
** Please note, the “Send to Archive” workflow has been developed to mitigate the problem when a
record set contains files which have been declared as a record (the inbuilt workflow cannot remove
document sets)
Team Collaboration
Historically teams tend to work in silos and this is mainly due to the inherent nature of the
“Team Site Integration Request Process” which tends to be scoped individually. This leads
to a “Bottom Up” approach which has a faster development time rather than the
recommended “Top Down” approach where it can take years to gather the required
governance and taxonomy data.
The team site collections are unable to collaborate by default and a solution has to be found
which can facilitate this.
For team collaboration the suggestions are; the Work Box which can be used for new
document libraries or a View Web Part as a navigation tool for existing document libraries.
The Work Box This has been developed for and resides in Codeplex and simply utilizes a
Site Collection (Similar to a record centre) with “Web Parts” bound to a team site to allow
access to the Work Box, this approach uses external sites to Share Documents. (Documents
are stored outside the Team Site Collection)
View Web Part. This is a suggestion for an in house development to combine a linked
Search Screen to bind to an external Team site collections using “Foreign Key” type filtering,
this allows access to documents which are located on other team site collections.