Microsoft SharePoint Online Dedicated
Custom Solution Policies and Process
Published: April 2010
For the latest information, please see http://microsoft.com/online.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO
THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document
may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this
document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
©2010 Microsoft Corporation. All rights reserved.
Microsoft, Access, Active Directory, Excel, Forefront, InfoPath, Internet Explorer, Outlook, PowerPoint, SharePoint, Silverlight, SQL Server,
Visual Studio, Win32, Windows, Windows PowerShell, and Windows Server are trademarks of the Microsoft group of companies.
All other trademarks are property of their respective owners.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
2
Contents
Introduction ................................................................................................................................................. 6
What Developers Should Know ................................................................................................................ 6
What Is New in the April 2010 Release .................................................................................................... 6
How Online Services Can Help ................................................................................................................ 7
Potential Impact of Deploying Custom Solutions ...................................................................................... 7
Deployed Custom Solutions ..................................................................................................................... 7
Use of Third-Party Solutions and Products .............................................................................................. 7
Third-Party Solution Licensing ............................................................................................................... 8
Open Source Project Support ................................................................................................................ 8
Customization Process .............................................................................................................................. 9
Timeline Overview of Customization Process ........................................................................................ 10
Key Milestones ..................................................................................................................................... 11
Requirements Gathering .......................................................................................................................... 12
High Level Design Review........................................................................................................................ 13
Scope of Customization .......................................................................................................................... 13
Hardware Evaluation .............................................................................................................................. 14
Customization Development .................................................................................................................... 16
Customization Testing.............................................................................................................................. 17
Using the Code Analysis Framework Tool ............................................................................................. 18
Customization Packaging ........................................................................................................................ 19
Package Requirements .......................................................................................................................... 19
Components............................................................................................................................................ 19
Customization Package Structure .......................................................................................................... 20
Solution Package Creation ..................................................................................................................... 22
Customization Package Submission ...................................................................................................... 22
Updating Existing Custom Code ............................................................................................................. 23
Online Services Testing, Validation, and Deployment .......................................................................... 24
Timeline for Online Services Review ...................................................................................................... 24
Online Services Operations Team Testing ............................................................................................. 25
Pre-Production Environment Validation .................................................................................................. 26
Change Advisory Board (CAB) Production Review ................................................................................ 27
Production Environment Deployment ..................................................................................................... 28
Re-Drop Policy for the Customization Package ..................................................................................... 29
Microsoft Engineering Policies for Custom Solutions .......................................................................... 31
System Monitoring .................................................................................................................................. 31
Patching Impacts .................................................................................................................................... 32
Updating a Customization ....................................................................................................................... 32
Break-Fix Remediation ........................................................................................................................... 33
Emergency Change Remediation ........................................................................................................... 33
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
3
Impact of SharePoint Online Upgrade on Customizations ..................................................................... 34
Service Policies ......................................................................................................................................... 37
Supported Customizations Policy ........................................................................................................... 38
Appendix A: SharePoint Developer Resources ..................................................................................... 42
Getting Started ........................................................................................................................................ 42
Webcasts ................................................................................................................................................ 42
More Development Resources ............................................................................................................... 43
E-Learning Resources ............................................................................................................................ 43
Best Practices for SharePoint Developers ............................................................................................. 43
Best Practices for Development Environments ................................................................................... 43
Development Environment Software Best Practices ........................................................................... 44
Automate Source Control and Build Process ...................................................................................... 45
Do Not Attempt Solution Versioning .................................................................................................... 45
Use Proper Namespaces for Customizations ...................................................................................... 45
Avoid Feature Versioning .................................................................................................................... 45
Use as Little Code as Possible in Application Development ............................................................... 45
Plan Carefully when Installing Dependencies ..................................................................................... 46
Limit the Number of Solution Packages in a Customization ................................................................ 46
Do Not Use ADO.NET to Connect to Databases ................................................................................ 47
Best Practices for Developing Code that Connects to an Internet Address ........................................ 47
Best Practices for Increasing SharePoint Site Performance ............................................................... 47
Configuring Caching ............................................................................................................................... 47
Using Content by Query Web Part Objects ............................................................................................ 47
Removing Unused Web Parts from SharePoint Pages .......................................................................... 48
Configuration Management .................................................................................................................... 48
Appendix B: Testing Resources .............................................................................................................. 49
Online Resources ................................................................................................................................... 49
Load Testing and Performance Resources ............................................................................................ 49
Best Practices for Testing ....................................................................................................................... 49
Scope of Testing .................................................................................................................................. 50
Microsoft Testing of Custom Solutions ................................................................................................ 50
Test Environments ............................................................................................................................... 51
Failure Points ....................................................................................................................................... 52
Appendix C: Solution Packaging Resources ......................................................................................... 53
Appendix D: Customization Package Checklist .................................................................................... 54
General Instructions ................................................................................................................................ 54
Scheduling Information ........................................................................................................................... 54
Deployment Guide (Installation Instructions) .......................................................................................... 54
Rollback Plan .......................................................................................................................................... 55
Solution Packages .................................................................................................................................. 55
Test Documents and Results.................................................................................................................. 55
Dependencies List .................................................................................................................................. 55
Event Log ................................................................................................................................................ 55
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
4
Client Troubleshooting Documentation .................................................................................................. 56
Source Code ........................................................................................................................................... 56
Third-Party Licensing Document ............................................................................................................ 56
Customer's Security and Compliance Review Document ...................................................................... 56
Monitoring Document .............................................................................................................................. 56
Update or Revision to an Existing Customization ................................................................................... 57
Appendix E: Building a Mirror Production Environment ...................................................................... 58
Test Machines......................................................................................................................................... 58
Appendix F: Implementing Master Pages ............................................................................................... 61
Prerequisites ........................................................................................................................................... 61
Introduction ............................................................................................................................................. 61
Sample Master Page Using Clarity Master Page Sample ...................................................................... 61
Appendix G: Troubleshooting Guide Templates ................................................................................... 67
Monitoring Troubleshooting Guide ......................................................................................................... 67
Support Troubleshooting Guide .............................................................................................................. 69
Appendix H: Approved Third-Party Solutions ....................................................................................... 70
Appendix I: Building Custom Solutions with Web Parts ...................................................................... 72
Appendix J: Code Development and Deployment Responsibilities .................................................... 75
Appendix K: Custom Solutions Using External Databases .................................................................. 77
Non-Supported SQL Server Features .................................................................................................... 78
Terms and Conditions ............................................................................................................................. 79
Database Configuration ....................................................................................................................... 79
Security Model ..................................................................................................................................... 80
Database Maintenance ........................................................................................................................ 80
High Availability Protection .................................................................................................................. 80
Connectivity and Access ...................................................................................................................... 80
Support ................................................................................................................................................ 80
Appendix L: Process to Escalate Customization Post-Deployment Issues ....................................... 82
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
5
Introduction
This document provides a description of Microsoft® Online Services (Online Services) support for
customization development and deployment to the Microsoft SharePoint® Online Dedicated environment.
There are three different types of customization available to the SharePoint Online customer:
1.
End-user customization. Customizations that are performed through a Web-based mechanism
(for example, style sheets and out-of-the-box Web Part and page templates).
2.
Authored site customization. Customizations that are performed by Web designers using
HTML editors such as Microsoft Office SharePoint Designer. These customizations apply, for
example, to master pages, page layouts, and data view Web Parts.
3.
Developed site customization. Customizations that are created by developers using the
development of Microsoft .NET–based code and dependent files that must be deployed on
SharePoint servers by the Online Services operations team.
This document applies only to the third type—customizations that require deployment by the Online
Services operations team—and that are installed and run on the SharePoint servers that are hosted by
Microsoft. These customizations include solutions or products that are developed by third parties, and
code developed in house by a customer development team. Custom solutions can be developed for
internal customer sites and for customer sites that are exposed to external users.
The custom solution development process that is outlined in this document can help ensure that code
deployed to the Online Services production environment is more secure, and that it is developed
according to established best practices. To that end, the Online Services engineering team reviews
proposed customizations, determines whether an out-of-the-box or existing solution can accomplish the
same goals, and then guides the process to ensure that the customization is deployable, supportable,
and sustainable by Microsoft support teams.
What Developers Should Know
It is assumed that the readers of this document are familiar with SharePoint development and Internet
Information Services (IIS), and know life-cycle–based development and testing of .NET-based code.
Resources for getting started with SharePoint development are included in "Appendix A: SharePoint
Developer Resources" later in this document.
The availability of the features described in this document is based on the Online Services release
process. Time to deployment varies from customer to customer. Customers should contact their service
delivery manager to discuss these features in relation to their organization.
Although SharePoint Online does not offer customers a hosted development or testing environment, we
do host a preproduction environment (PPE) for customers to validate customizations prior to production
deployment. see "Appendix E: Building a Mirror Production Environment" later in this document.
What Is New in the April 2010 Release
Previously, Microsoft SharePoint Online custom code development required that the customer create a
customization, test it, and then hand it off to Microsoft to validate the code. Now, most of the validation is
done automatically using a tool called the Microsoft SharePoint Online Code Analysis Framework (CAF).
The tool validates the solution code to ensure that it is built using most of the known best practices. It also
checks the solution for security flaws and for memory leaks. Note that the tool only performs code
validation of the solution, so functional and stress testing must still be done by the customer's
development team.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
6
How Online Services Can Help
Customers who want to develop and deploy custom SharePoint solutions benefit from Microsoft Online
Services involvement in the following ways:

Structured process. SharePoint Online uses a structured review process that pairs Microsoft
partners or employees with customers to help mitigate the risk of falling outside of the established
goals for solution performance, scalability, availability, and upgrade.

Experience deploying custom-built solutions. SharePoint Online has extensive experience
with deployment of customer solutions as well as purchased and custom-written third-party
solutions.

Capacity planning experience. SharePoint Online has experience evaluating the impact of
custom code and the necessary changes that are required to scale hardware and logical
infrastructure design to meet customer needs.
Potential Impact of Deploying Custom Solutions
Custom code has the potential to significantly impact the SharePoint Online environment—especially
when the code generates a high load, requires significant resources, or doesn't scale to the current
environment. To address these issues, it may be necessary to purchase additional hardware, upgrade
existing hardware components, scale back custom solution deployment by deploying to fewer sites or
pages, or revoke the solution entirely. During the review phases, the Online Services engineering team
identifies the need for additional hardware or upgraded components to support the customizations that
are provided by customers. In cases where supporting the customizations would require additional
hardware, Microsoft reserves the right to reject the customization or to charge for the additional hardware
required. Adding additional hardware could delay the deployment of the customization.
Important
Because SharePoint Online does not offer a hosted development or testing environment, all
development and testing must take place on an environment that is hosted by the customer or a
partner. PPE is not a substitute for a customer-hosted or partner-hosted test environment, and it does
not become available to the customer until after the customization package has been submitted to the
Online Services engineering team for review.
Deployed Custom Solutions
Deployed customizations are monitored by the Online Services operations team, based on the necessary
monitoring rules that are provided by the customer. If custom code has an adverse impact on the Online
Services customer experience, or if it affects the ability of Microsoft to meet the customer's service level
agreement (SLA), the Online Services operations team takes immediate action. This may include
debugging the application and optimizing it for current load and stress conditions, or removing of the code
to return the environment to a stable state. If this occurs, an emergency Change Advisory Board (CAB)
meeting is called and the customer is consulted to make the best decision possible. For more information
about post-deployment issues, see "Appendix L: Process to Escalate Post-Deployment Issues Related to
Customizations" later in this document.
Monitoring of customizations is effective only if customers provide complete and usable troubleshooting
guides, as well as instrument custom event codes. In addition, the customizations must implement the
proper instrumentation to support monitoring.
Use of Third-Party Solutions and Products
Third-party solutions and products are available from both developers and vendors for installation in the
Online Services environment. In most cases, these products are eligible for installation if they qualify as
an allowed customization as described in "Permitted Customizations Policy" later in this document.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
7
SharePoint Online has evaluated only a limited number of third-party solutions at this time. A full list of the
approved third-party standalone solutions can be found in "Appendix H: Approved Third-Party Solutions."
As more standalone solutions are evaluated and approved, they get added to the list of prequalified
solutions and products that are eligible for installation without the need to go through the evaluation
process. Microsoft’s service manager or solution architect assigned to each customer has access to an
up-to-date list of all preapproved third-party solutions and products.
Some prequalified customizations may also require changes to the hardware resources or support
resources associated with a customer's deployment.
Third-Party Solution Licensing
The customer is responsible for obtaining the licensing for any third-party solution or product, and must
provide proof of this licensing (often a key or certificate) as a part of a customization package. Depending
on the third-party solution, a second set of licenses may also be needed for the disaster recovery server
farm as the first set of licenses may only apply to the production server farm.
Open Source Project Support
SharePoint Online supports open source code if the customer first takes responsibility in writing for the
ownership of the code, and ensures that such code has been tested for performance, scalability, stability,
data integrity, and sustainability. The customer is also responsible for end-to-end support of open source
code. When deployed to the production environment, if Microsoft encounters any issues that are related
to such open source software, it transfers to the customer any issues for further root cause analysis and
triage.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
8
Customization Process
Introducing custom code within the SharePoint Online production environment—or revising existing
code—requires following a development and deployment process that has been established by Microsoft.
This process is based on best practices developed by Microsoft through its work with the hosted
SharePoint Online Dedicated service. It is also closely aligned with the processes described in the
Microsoft Solutions Framework and the Microsoft Operations Framework. For more information about the
Microsoft Solutions Framework, download Microsoft Solutions Framework version 3 white papers. For
more information about the Microsoft Operations Framework, see Microsoft Operations Framework 4.0 in
Microsoft TechNet.
The development and deployment process for custom code is outlined in this section. The process
applies to the development of new or updated code that is intended to be installed and run on production
environment servers.
The core deliverables of this process are the High Level Design (HLD) document and the Customization
Package which contains the Deployment Guide. The HLD document is the high level technical
explanation of the customization. The Deployment guide is contained within the customization package
and includes the detailed technical explanation of the customization, deployment and verification steps
and other important information. The Customization Package also includes the solution packages (final
tested code, install and uninstall scripts), the source code, and all related documents, such test
documentation.
An overview of the customization process is shown in Figure 1.
* Business days
** Customers must submit HLD and code drops along with updated versions of the Change Request templates.
Figure 1. Overview of SharePoint Online customization process
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
9
Timeline Overview of Customization Process
This section presents an overview of the time and resources that are generally involved in the custom
solution development and deployment process, using a sample timeline and process for the deployment
of custom code. Steps 2 through 6 are detailed in later sections of this document.
As shown in Figure 1, a typical timeline proceeds as follows:
1. Requirements gathering. Depending on the complexity of the customization, the customer's
development team may require up to four weeks (20 business days) 'to gather requirements and
buyoff from the project sponsor and stakeholders.
2. Create HLD document. At least five days prior to submission of the HLD document for review, the
customer must notify the SharePoint Online service management team via the customer's technical
account manager (TAM) about its intent to submit the HLD document.
Note: Throughout the entire customization process, all communication with SharePoint Online,
including the delivery of the customization package to the Online Services engineering team, is
handled by the customer's TAM.
3. Review HLD document. The development team submits the HLD document to the Online Services
engineering team for review and approval prior to code development. Microsoft has five business
days to respond to the HLD after submission by the development team. We recommend that no
development work be done until the HLD has been reviewed, to allow any feedback to be
incorporated into the development. Until the Online Services engineering team formally accepts the
HLD, Microsoft does not accept any customized code for review and testing.
4. Customization development. After the Online Services engineering team approves the HLD, the
customer's development team starts customization code development.
5. Customization testing, CAF validation, and packaging. The customer provisions a team to test
the customization internally, validate the solution, document the testing and other aspects of the
solution process, and build customization packages.

Testing. The customer's development team must include tests for scale and performance.
Because the current release of the Microsoft SharePoint Online Code Access Framework (CAF)
application does not integrate with CAT.NET, the customer must run CAT.NET to analyze their
customization code. For more information about CAT.NET testing, see "Best Practices for
Testing" later in this document.

Validation. The customer's development team uses the CAF application provided by SharePoint
Online to validate the code of the customization. Also, manual test cases not included in CAF
should be validated by the customer (if applicable to the customization) and submitted using the
Test Results document.

Packaging. The customer's development team begins preparing the customization package,
which consists of all solution documentation, all code components, and the CAT.NET report. This
typically takes about 10 business days, but depends on the complexity of the customization.
Five business days prior to the intended code drop date, the customer must notify the SharePoint
Online service management team through the customer's TAM that a customization package, with
final documentation and source code, is being provided for review.
The customer submits the customization package to the Online Services engineering team at least 16
business days prior to the change window in which the customer wants to deploy the customization.
6. Online Services testing, validation, and deployment. The Online Services engineering team
typically takes 10 business days to review and validate the customization, and to test the code in an
Online Services internal lab environment. Deployment occurs first in the PPE environment, and then
in the production environment.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
10

Validation. The validation is intended to confirm that the solution is supportable and matches the
details of the HLD document. SharePoint Online uses the CAF application, as well as manual
tests, to validate the customization.

Testing. The choice of manual tests depends on the customization type. For example, if the
customization is a master page then there is a test that validates that the sites will have the
correct look and feel when the feature is enabled. There are tests to verify that when a feature is
disabled, the look and feel reverts to the previous version. The Online Services operations team
also tests that the Web.config files are correctly updated when the customization is activated, and
that the changes are reverted when the customization is deactivated.

PPE deployment. The deployment request is reviewed in a Change Advisory Board (CAB)
meeting at Microsoft (one business day). After approval by the CAB and a successful initial
review, the Online Services operations team deploys the solution to the PPE if it is available, and
performs customer-provided validation steps.

Production deployment. In parallel with the PPE review by Microsoft, the customer
development team also has five business days to review the customization in the PPE and sign
off for deployment to the production environment. When the customization receives validation
from both the Online Services engineering team and the customer development team, the
production deployment request is submitted to the CAB.
When approved by the CAB, the Online Services operations team prepares for production
deployment (four days). Deployment occurs at the next scheduled change window, usually on a
Friday. The Online Services operations team performs the validation steps provided by the customer
and then contacts the customer development team to perform any post-deployment actions. For more
information about the deployment window, see Production Environment Deployment.
Key Milestones
Table 1 shows key milestones that the customer must understand to ensure a successful deployment of a
customization to their SharePoint Online PPE and Production environment.
Table 1. Timeline for Deployment
Action
Duration
Customer notification to Online Services operations team before submitting HLD.
5 business days
Turnaround time for Online Services operations to complete HLD review.
5 business days*
Notification by customer to Online Services operations before submitting customization
package.
5 business days
Turnaround time for Online Services operations to complete customization package
review.
10 business days*
* Assumes that Online Services operations team requires no additional information from the customer to process the
review.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
11
Requirements Gathering
As a formal part of any development, requirements should be gathered from all stakeholders: developers,
support personnel, end users, and testers. When factoring in all of the requirements, it is important to
consider scale (for example, multiple Web front-end servers) and performance (such as page load time
and latency).
Customer requirements influence both how the code is developed and how it is tested. For a customer
with multilingual requirements, unit testing requirements should specify that testing is performed in each
localized language. SharePoint Online uses language packs, master pages, page layouts, resource files,
and administrator interface that are specific to a locale. In some cases, the customer must ensure that the
custom application renders correctly when the page is read right to left or if the language contains doublebyte characters. The customer does not need to submit a formal statement of requirements to Microsoft.
However, specific constraints related to such factors as performance, scale, and language should be
noted both in the HLD document and later in the test plan.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
12
High Level Design Review
The HLD review is the process that helps SharePoint Online, or its designated partner, to work with the
customer in providing an initial evaluation of the customer's proposed customization.
To start the process, SharePoint Online requires the customer to gather and present information about
the proposed customization using the HLD document. We recommend that the customer request the
template for the HLD document, which is available from the customer's TAM or solution architect. The
completed HLD document is submitted to the Online Services engineering team for review and approval
prior to code development.
The HLD review has the following goals:

Provide SharePoint Online the opportunity to suggest an out-of-the-box solution or a previously
evaluated third-party solution instead of custom development.

Provide feedback to ensure that the design implementation follows established best practices and
receives guidance from experienced SharePoint developers.

Evaluate the design to determine whether it is supportable within the Online Services hosted
environment, and if it poses any risk to the existing environment or the SLA.

Minimize the likelihood of having to rewrite or change the solution when service packs and future
versions of the product are released.

Determine whether additional hardware is needed to support the customization.

Capture potential performance issues early, rather than during testing or after production
deployment.
The following information helps with submission of the HLD document:

The Online Services engineering team must receive notification five business days in advance
that the HLD document will be submitted.

If usage patterns, audience, hours of usage, or similar characteristics are likely to change as a
result of a new customization, that information should be included in the HLD document so that
resource considerations can be taken into account early.

The Online Services engineering team has five business days to respond to the HLD document.

During the HLD review, Microsoft or a designated partner notifies the customer if the solution
packages will require a longer validation and review period than the standard 10 business days
allocated for this phase. In this case, the Online Services engineering team provides an estimate
of the amount of time that will be required to review the customization.
Scope of Customization
The HLD review provides the Online Services engineering team with an opportunity to review the scope
of the planned solution and determine whether it is a small, medium, or large customization based on the
amount of code and number of Windows® SharePoint Services solution package (WSP) files that will be
included in the customization package. (For more about solution packages, see "Customization
Packaging" later in this document.) Table 2 shows how customization sizes are determined.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
13
Table 2. Customization Sizes
Solution Size
Lines of Code
Number of WSP Files
Small
0 to 1000
1 to 2
Medium
1000 to 3000
1 to 4
Large
3001 or more
1 to 10
Important
Customizations that are determined to be extremely large and complex (requiring the full time period
to review) will not be eligible for a re-drop (a resubmission by the customer of any part of the
customization package) during the evaluation and production deployment phase of the customization
review process. We recommend that the customer development team consider breaking up a large
project into multiple phases that are evaluated and deployed at different times.
In general, the development team can anticipate the solution type based on its size, as indicated by the
criteria in Table 2. However, a solution that is more complex than normal, has dependencies on a
significant number of external systems, or processes a large amount of user-provided content may be
classified differently despite a small amount of code or number of WSP files. Upon submission of such
complex customizations, Microsoft notifies the customer if additional time is necessary to complete the
review.
If the development team is designing a solution that will require more than 10 WSP files, the team should
reconsider its architecture. It is difficult to manage and deploy so many solution files within a single
deployment window, and the solution risks rejection because of the complexity for the Online Services
operations team of managing it.
Hardware Evaluation
The HLD review is performed based on the customer's current load and hardware configuration. In some
cases, an HLD review may reveal the need for a new hardware component; for example, a multipart
customization may require deployment of additional servers, or upgrades to existing servers, to meet
performance expectations and SLA requirements. In certain cases, additional resources and operational
support may be necessary. The Online Services engineering team reserves the right to reject any
customization that requires the addition of hardware or resources above and beyond what is already
provisioned for the customer.
Microsoft Responsibilities
 Return an evaluation of the HLD document within five business days of receiving the document
from the customer, or immediately notify the customer if more than five days will be needed for
review.

Evaluate the HLD document against the existing infrastructure and resources, and notify the
customer if the customization requires changes.

Evaluate whether the standard 10-business-day evaluation period will be adequate to validate the
customization when complete.

Contact the customer immediately if problems are discovered during the review process.

Evaluate whether an HLD reveals a small, medium, or large customization. Large customizations
are not eligible for a re-drop during the evaluation phase.
Customer Responsibilities
 Complete the HLD document before any coding takes place.

Notify the Online Services engineering team at least five business days before the HLD document
is submitted, to ensure that SharePoint Online possesses the necessary resources to evaluate it.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
14

Provide a developer resource to respond to questions or concerns in order to achieve signoff
within the window of five business days.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
15
Customization Development
Following approval of the HLD, the development team can begin code development. The customer is
responsible for developing or purchasing the customization and operating its own development
environment. The customization should be developed in an environment that matches the SharePoint
Online production environment. For details about how to build an environment that matches the
SharePoint Online production environment, see "Appendix E: Building a Mirror Production Environment"
later in this document.
For customers who are new to development for SharePoint Online, we highly recommend that a customer
team perform the following actions:

Plan a proof-of-concept before doing a full-scale production development.

Use a source control system for storing and tracking customization code.
Furthermore, we strongly discourage running code with full administrative privileges.
In addition, the customer development team should ensure that any dependencies of the customization
should rely only on the custom code itself. Any configuration changes should be implemented in a way
that minimizes the need for manual steps by the operations personnel who deploy the solution.
Information and resources about development in the SharePoint environment are available in "Appendix
A: SharePoint Developer Resources" later in this document.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
16
Customization Testing
As with development, testing is a customer responsibility. SharePoint Online does not offer a customeraccessible testing environment, so testing code and maintaining a test environment is the responsibility of
the customer.
Note: The customer is solely responsible for the testing of the solution. The customer must test all
components of the solution, whether developed by the internal customer development team or
purchased from a third-party vendor, before sending it for evaluation and deployment by the Online
Services engineering team. These tests should include, but may not be limited to, functionality,
performance, stability, scale, and full unit testing.
Insufficiently tested code represents a risk to the entire Online Services environment. If the Online
Services engineering team has sufficient concern that a customer has not adequately tested the code, the
code is rejected during the review process.
If a customization is depending on integration or communication with services, data, or systems that are
unique to the customer's corporate environment, then the Online Services operations team will be unable
to reproduce this within its own testing environment. However, when evaluating code in the PPE, the
customer can test whether these forms of integration are working as expected. When performing these
types of integration tests, we recommend that the customer provides and uses connections to a user
acceptance test (UAT) version of the customer's service, data, or system to avoid negative impact to the
production environment. However the customer chooses to handle this aspect, testing must be performed
adequately within the customer's environment and then later documented in the customization package.
Important
It is important to recognize that the PPE is not a substitute for a test environment; it is simply a
validation environment.
It is very important that the customer provision a dedicated test team that is familiar with the customer's
production version of Microsoft Office SharePoint Server. The test team should be able to distinguish the
difference between defects in a customization versus an out-of-the-box solution that is working but is not
behaving as desired. Testing must cover the entire solution life cycle (for example, installation, activation,
creation of content, editing of content, and finally expiry or deletion of content).
We recommend that the development team have a full formal test pass before handoff to the customer's
own test team, to minimize the number of defects.
Important
Development and testing should be done with the same Microsoft Office SharePoint Server version,
including the patch levels, that is installed on the customer's hosted environment.
Prior to development, the customer should check with Microsoft to determine whether any patches are
scheduled to be installed prior to deployment of the customization solution. It is the customer's
responsibility to ensure that development and testing has been done using the appropriate version of
Office SharePoint Server. Office SharePoint Server 2007 patches are cumulative; as a general rule, they
'cannot be rolled back in a production environment after being deployed.
To learn from Microsoft experience with internal testing of the customer environment and internal testing
of custom-developed code for SharePoint Online, see "Best Practices for Testing" later in this document.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
17
Using the Code Analysis Framework Tool
The customer must use the Microsoft SharePoint Online Code Analysis Framework (CAF) tool to validate
the customization prior to submission to the Online Services engineering team. The CAF application
includes a user's guide in a compiled help file. The CAF tool may be downloaded from the Microsoft
Online Services customer knowledge base site.
The CAF tool performs a rules-based code analysis of the solution to establish whether it is built using
known best practices. The report generated by the CAF tool instructs developers on the parts of the
solution that need changing in order to meet the validation criteria. SharePoint Online reserves the right to
add new rules to the CAF engine; however, new rules are not retroactive. They will only apply to new
customizations or to updates of existing customization.
Code analysis focuses on areas like memory management, security vulnerabilities, exception
management, object model usage, quality gates for unsupported features, and reporting. The framework
uses existing tools like FxCop and SPDisposeCheck for analyzing the customizations. The elementary
unit of execution for the CAF tool is a check for best practices or for recommended guidelines as
prescribed by the Online Services operations team. Rules of similar category are grouped together while
creating a test case. These test cases are then run during the analysis of the solution packages.
SharePoint Online also provides a document of manual test cases, outside the scope of the CAF tool,
that Microsoft uses to validate customer solutions. The Test Cases document is available for all existing
SharePoint Online Dedicated customers at the Microsoft Online Services customer knowledge base site.
The customer is must run these manual tests on the customization prior to submission.
Microsoft Responsibilities
 Provide guidance about all installed builds and patches within the SharePoint Online
environment.

Provide guidance about how the production environment is built so the customer can create test
environments that adequately mimic the production environment.
Customer Responsibilities
 Build and maintain development and test environments.

Adequately test all custom code before submitting it to the Online Services engineering team for
validation.

Outline and test any requirements concerning performance, scale, and language.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
18
Customization Packaging
When custom code development and testing are finished, the customer development team must create
and present a customization package—including adequate documentation—to the Online Services
engineering team for testing and analysis prior to deployment in the production environment. Testing by
Microsoft does not begin until all documentation and final code are delivered.
Package Requirements
The following are requirements for submitting customizations:

Documentation is required, whether submitting a new customization or an update to an existing
customization. Several types of documents must be created; for a summary see Table 3.

The solution itself, and the customization package as a whole, should have meaningful titles.
(The two can have the same name.) For example, "Jan_26_customization" is too general to be
an appropriate title. The customization package should be titled in this form:
"CustomerName_CustomizationTitle_Version". For multiple solution packages, each can have
this form: "CustomerName_CustomizationTitle_Solution-SolutionName".

When packaging code and documentation into the customization package, the customer must
compress the entire package using the .zip file format. Other third-party compression tools are
not permitted for installation on host data center computers, and SharePoint Online does not
repackage the customization package if the incorrect compression tool is used.

The customization package should be submitted through the TAM by creating a change request.
When preparing the solution packages and the documentation for the customization package, it is
important to know that all customization packages are deployed to both a primary and a secondary data
center; the secondary data center is maintained for disaster recovery. Deployment instructions should
note which package components must be run, installed, and deployed in which data center. For example,
scripts to create a custom database only run once, and only on the primary data center, but SharePoint
Online solution packages must be deployed to both data centers.
Microsoft Responsibility
 Provide guidance on the structure of the customization package.
Customer Responsibilities
 Package all of the final tested customization code as WSP files. (This step is required for all inhouse development.)

Include detailed validation steps in the deployment guide so that MSO can verify that the solution
is working as expected post-deployment.
Components
The customization package should be organized in an easy-to-follow file system. For example, folders
should be used to separate source code, final tested code, and release documentation. The Deployment
guide specifies the folder structure that should be followed when submitting a customization. The
components of the submission should be organized according to the following guidelines:

The customization package must have a folder called "Release Documents" that contains all the
relevant documents related to the release.

The test documentation must be in a folder called "Test Documents".

The solution packages, including final tested code, must be in a folder called "Solution
Packages," although this is not required for submission. The CAF uses this directory to create a
CAB file which should be placed in the root directory.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
19

If there are any scripts that must be run as part of the installation, they must be in a folder called
"Installation Scripts".

The source code must be in a folder called "Source Code".
Table 3 presents an overview of what must be included in the customization package. Complete details
are included in "Appendix D: Customization Package Checklist" later in this document.
Customization Package Structure
One of the elements that the CAF tool checks is the customization package structure. The customization
package that is sent to SharePoint Online must adhere to the directory structure shown in Table 3. For
more information on CAF, see "Using the Code Analysis Framework Tool" earlier in this document.
Table 3. Customization Package Components
Package
Component
Directory
Description
Scheduling
information
Release Documents
State the expected date for code-drop submission and deployment.
Also include the expected duration of downtimes for deployment
configuration and post-deployment configuration.
Deployment guide
Release Documents
Online Services operations team provides a deployment guide template
for customers to submit as part of the customization package.
The deployment guide includes details about how to install all of the
customization package components, any architecture diagrams that are
related to the installation of the custom code, and procedures for how
to test that the solution packages and the solution as a whole have
been properly deployed. It also includes a list of prerequisite software
and any open source software used in the customization. (The
installation and uninstall scripts are handled in a separate section of the
customization package, below.)
Include detailed verification steps (in the deployment guide so that
Online Services operations can verify that the solution is working as
expected post-deployment, including any telltale signs, GAC versions,
or even screen shots of the environment that indicate successful
deployment.
The deployment guide must be completely self-contained. Do not
include references to e-mail threads or other documentation, or else the
customization package will be rejected. For customers who are using
third-party solutions, pointers to the vendor's installation documentation
are not suitable documentation.
Open/shared source
code waiver
Release Documents
If any open source or shared source code or components are used in
the solution, the customer is required to provide a waiver in writing
stating that the customer will be responsible for supporting any issues
that arise from the use of open source software.
CAF report
Release Documents
Include the CAF report on the final code drop. Also include all the
exception comments from the exceptions found by the CAF tool as part
of the report.
Rollback plan
Release Documents
Provide a rollback plan, in case the customization must be removed.
Include screen shots of how the environment must look after a
successful rollback.
Note: If it is not possible to roll back a solution, this must be called out
in the deployment guide so that the risks can be discussed between
SharePoint Online and the customer development team and any
preparations for a system recovery can be planned by both teams.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
20
Package
Component
Directory
Description
Solution packages
Solution Package
Include the final versions of all the solution packages, including final
tested code and the CAF report, in this folder.
Installation scripts
Installation Scripts
Store all installation and un-installation scripts (such as Windows
PowerShell™ scripts and batch files) in this folder, including a tailored
set for the secondary data center, if warranted.
Test documents and
results
Test Documents
For testing and validation purposes, it's extremely important to supply a
copy of the solution test plan, test scenarios, unit test results, and all
performance and scale testing that has been performed related to the
code. This is even more important if the code has a dependency (Web
service, data, or system) that cannot be tested during SharePoint
Online acceptance testing.
Include details about all elements of the customization that the
customer wants deployed, including any third-party components and
other solutions that the customer has purchased.
Dependencies list
Release Documents
Submit a list of all dependencies for the code. This can include an
account and password, Web services, databases, other solutions,
features, patches, tool sets, and libraries.
Event log
Release Documents
Provide a list of all event entries generated by the customization, and
the troubleshooting actions to take for them. The list commonly takes
the form of a table of error codes, the corresponding severity, and root
cause.
Client
troubleshooting
documentation
Release Documents
Submit end-user troubleshooting guidance for the Online Services
Operations team and one or two test accounts, if appropriate, to
diagnose problems that are related to the customer's dependencies. If
an account is provided, it should be set up with low privilege and used
for no other purpose.
A template is provided in "Appendix G: Troubleshooting Guide
Templates," later in this document, to show the correct format for the
client-facing Troubleshooting Guide.
Source code
Source Code
Include the project files and source code (validated through the CAF
tool), where developed in-house. All source code is treated with utmost
confidentiality by Microsoft. Details about the treatment of customer
source code can be found in the customer's contract, in the section
"Pre-Existing Work".
Note: If the solution is a third party off-the-shelf application, no source
code is needed for submission.
Public debug
symbols
Source Code
To aid in the possible troubleshooting scenarios, include the public
debug symbols for all custom code.
This symbol file is automatically created by Microsoft Visual Studio® as
long as either "pdb only" or "full" is selected from the Debug Info
setting, which can be accessed via the Advanced settings on the Build
page in Visual Studio. For more information, see the article "PDB Files
(C# and Visual Basic)" in the Visual Studio Developer Center.
Third-party licensing
document
Release Documents
Provide the licensing details and, if necessary, keys or certificates for
installation, if using a third-party component or solution. Include all
details about the testing that has been done against the third-party
component or solution.
Note: Remember to purchase licenses for both the primary and
secondary data center computers.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
21
Package
Component
Directory
Description
Customer's security
and compliance
review document
Release Documents
We recommend that customers have their own security and compliance
team review and approve all customizations that are being presented to
Online Services for deployment. Include the customer's Security and
Compliance Review approval of the design, and all test details from this
review process.
Monitoring
document
Release Documents
Provide all details related to monitoring the customization, including
logging details and documentation about all instrumentation.
Solution Package Creation
SharePoint Online requires the use of Windows Solution Package (WSP) files to deploy customizations to
the SharePoint Online environment. A solution package is a compressed .wsp file—Windows Solution
Package file— that consists of the various resources necessary for deploying the solution. A custom
solution may include several solution packages to contain all the components of the solution. There are
several advantages of deploying with solution packages :

The packages are stored on a SharePoint Server, and can be redeployed to existing or new
servers as they are brought online.

The packages are completely self-contained and do not generally require tracking of a specific
installation order.

The packages can be deployed very quickly to a new server farm for disaster recovery of the
SharePoint Online environment.
Components that can be packaged in a solution package .wsp file include:
 Microsoft .NET Framework assemblies.

Deployment files such as .aspx files, master pages, and page layouts.

New templates and definitions for such components as lists, libraries, fields, and content types.

Configurations that must be carried out at the Web-server level (for example, the Web.config files
for the registration of Web Part assemblies).
These solution packages can be built within the Visual Studio development system or manually. Each
solution package is stored as a WSP file, and a custom solution sometimes requires numerous WSP files.
If the development team is designing a solution that requires more than 10 WSP files, the team should
reconsider its architecture. It is difficult to manage and deploy so many WSP files within a single
deployment window, and the solution risks rejection because of the complexity for SharePoint Online of
managing it.
Some solutions that are developed by third parties might not use solution packages, and yet might be
acceptable to the Online Services operations team that is reviewing the package. However, all custom
solutions that are developed by an in-house customer development team must use the WSP packaging
technology. For further details about solution packaging and WSP files, see "Appendix C: Solution
Packaging Resources" later in this document.
Customization Package Submission
The delivery of the customization package to the Online Services engineering team is handled by the
customer's TAM. The customization package must be delivered at least 16 business days before a
scheduled change window, to ensure that the deployment can be implemented in a timely manner in the
production environment.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
22
Custom solution deployments are implemented during Microsoft-defined change windows. The customer
should be aware of the scheduled change windows when submitting the customization package for
review. Each customer receives a change window calendar that contains the available windows during
which customizations can be deployed.
The 16-day lead time enables SharePoint Online to schedule resources, build a lab environment in
preparation for testing, and perform testing. It also provides time to obtain approvals from the Change
Advisory Board (CAB), and to ensure that SharePoint Online has adequate staffing on hand to ensure a
successful deployment.
For more information about designated change windows, see the SharePoint Online Change Calendar
documentation, which is available from the customer's TAM or the SharePoint Online customer
knowledge base site.
Updating Existing Custom Code
When updating an existing customization and therefore existing documentation, the following should be
provided in addition to the components detailed in Table 3:

A summary of what has changed from the previous version. This summary must include
what has changed (for example, "Master page layout changed, referenced a new CSS file, and
updated the underlying JavaScript.").

Design changes. If the design has changed and now requires a feature enhancement or other
change to functionality, customers must submit an HLD document.
If existing custom code is being updated only to address bugs, with no fundamental design
changes, no HLD document is necessary. The customer can provide a heads-up five business
days prior to the designated code drop window, through the TAM, and submit the customization
package (including updates to the source code, deployment guide, and any other component
from the package as needed) for Online Services operations team to review. The review process
takes up to ten business days.

The original solution source code. As a part of solution analysis, the new source code is
validated against this original source code to ensure that no issues were introduced with the
planned change.

Anticipated problems during upgrade. Submit details about any errors, rendering issues, or
other problems that might be expected when upgrading the customization.

Updated support documentation. Include updates for the end-user troubleshooting guide and
other documents. Describe anything that has changed and any new features that could potentially
require support or monitoring.

Rollback steps. The rollback steps must include the necessary scripts for retracting the solution
and adding the previous version of the solution. Any change to a custom solution requires that the
customer submit a complete new package for review that covers the updated solution.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
23
Online Services Testing, Validation, and Deployment
After the customization package is delivered to SharePoint Online, the Online Services engineering team
reviews and validates the customization to ensure that the solution is supportable, and that it matches the
details of the HLD document. The engineering team may also perform tests in an Online Services internal
lab environment. During that time, the customer may also have the opportunity to test the customization
in a pre-production environment (PPE). Preparation for deploying to the production environment is the
final step in the process.
Important
If it is necessary for the customer to deliver a new version of the code after validation begins,
SharePoint Online must reset the validation process, and the original deployment window is placed at
risk.
Timeline for Online Services Review
SharePoint Online begins analysis and pre-production testing after the customization package is
delivered. Here is an example of the timing of a typical customization package handoff and review:

Package delivery notification. Five business days prior to the intended code drop date, the
customer must notify the Online Services engineering team, through the TAM, that a customization
package, including final documentation and source code, is being provided for review.

Package delivery. The customer submits the customization package to SharePoint Online at least
16 business days prior to the change window in which the customer wants to deploy the
customization.

Engineering team review: testing and validation. The Online Services engineering team begins
reviewing the submitted customization package; this takes 10 business days. This step includes
testing the code in an Online Services internal lab environment and validating the customization.

Initial CAB review. If the PPE is available, the Change Advisory Board (CAB) spends one day
reviewing the solution prior to PPE deployment. (For more information about the PPE, see "Error!
Reference source not found." later in this section.)

Engineering team deployment decision. Based on the review of the deployment package, the
Online Services engineering team approves or rejects deployment of the customization package to
the PPE. If a deployment is rejected, in some cases a resubmission is possible within the same
deployment window. See "Re-Drop Policy for the Customization Package" later in this section for
details.

PPE solution deployment. The approved customization package is deployed to the PPE
environment, if the PPE is enabled for that customer. Otherwise, it is pushed to the production
environment.

Customer PPE review. The customer team reviews the solution in the PPE for five days. The
customer team then approves or rejects deployment to the SharePoint Online production
environment.

Final CAB review. The CAB reviews the testing and validation results after both the Online Services
engineering team and the customer team have approved production deployment.

Operational deployment preparation. SharePoint Online spends four days preparing for production
deployment and waiting for the change window. The standard deployment windows are scheduled for
Fridays.
Figure 2 is an example of the customization package review and testing schedule.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
24
Figure 1. Customization package review and testing schedule
Customer Responsibilities
 Notify SharePoint Online at least 21 business days before the scheduled Microsoft change
window.

Provide a complete customization package to Microsoft at least 16 business days before the
scheduled change window.
Online Services Operations Team Testing
In parallel with customer testing of the deployment in the PPE, the Online Services operations team may
perform the following tests in an Online Services internal lab environment separate from the PPE:

Run the CAF application and manual test cases to analyze the solution packages.

Evaluate solution packages and installation/uninstall scripts.

Check for memory leaks.

Determine whether error handling and exception handling are sufficient.

Ensure that the code falls within the customization policy.

Make sure that elevated privileges follow best practices.

Determine that all code is fully trusted.

Ensure that unmanaged code is properly handled.

Check compatibility with current production version of Office SharePoint Server.

Test for security vulnerabilities.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
25

Follow development best practices.
This testing and analysis attempts to evaluate the following:

Supportability of the code on the customer's architecture within the Online Services hosted
environment.

Dependencies that may pose conflicts or risks.

Quality of error handling when dependent components are not available to the code.

Adequacy of the documentation: that it describes the custom code that has been provided, details
all dependencies, and demonstrates that the customer has done adequate functional unit testing.
Core functionality is occasionally tested, including the deployment footprint on the installation, to ensure
that the application does not make an unnecessary or potentially harmful change to the service. Aesthetic
aspects of the solution code for those solutions—the user interface, for example—are disregarded. It is
the customer's responsibility to ensure that the customization meets its own requirements and fulfills the
anticipated need.
The code is not formally unit tested. In some cases, if the dependencies (Web services, data, or systems)
are not available in the Microsoft Online Services internal lab environment, the code can't be tested. In
these cases, Microsoft does review the code, and tries to establish that adequate testing has been
performed by the customer, based on the documentation provided. Customers are encouraged to test
dependencies within the PPE prior to the production deployment.
Pre-Production Environment Validation
Microsoft provides a pre-production environment (PPE) so that customer development teams can validate
customizations before moving on to the production environment.
The PPE is a scaled-down replica of the production environment that matches production configuration.
This enables validation of custom solutions prior to deployment in a production environment, and
validation of existing production custom solutions against a new version of Office SharePoint Server
(patch, service pack, major release). The PPE is not subject to an SLA or availability KPI. For more
information about the PPE environment, review the "SharePoint Online Customer Handbook" located at
the Microsoft Online Services customer knowledge base site.
The virtualized PPE environment is designed to have the same logical architecture as the production
environment, with the following restrictions:

The total volume of content does not exceed 150 gigabytes (GB).

The total number of content databases per Web application does not exceed 2.

Up to 250 concurrent users can access the PPE at the same time.

The PPE is not configured to send mail.
The PPE validation process begins with the customer submitting a new or updated customization
package to Microsoft. Microsoft reviews the design and documentation at the weekly CAB meeting. Only
after approval from the CAB can the solution be implemented in the PPE for validation. Deployment to the
PPE usually occurs approximately one week after the package is submitted to Microsoft, and following
CAB approval.
Note: The PPE environment is not intended for scale and performance testing—it is intended
only for performing the UAT/smoke testing of the customization.
After the solution is installed in the PPE, the customer can access the solution to do the following:

Validate the solution in a user acceptance test (UAT) environment before production deployment.

Provide designated users access to the solution prior to going live in production.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
26

Validate existing custom solutions (solutions that are currently in production) with SharePoint
Online upgrades or updated custom solutions.
Microsoft Responsibilities
 Provide a dedicated, hosted PPE to validate the customer solutions.

Deploy the custom solution following the customer's installation guide.

Test that the customization is successfully deployed using the test process provided by the
customer.

Provide data connections to existing data connections, systems, or services within a UAT
scenario.

Maintain the environment to ensure that it replicates the current settings and configurations in
production.
Customer Responsibilities
 Verify that the solution is working as expected according to the customization project schedule.

Provide details about what has changed, in the case of an update to an existing solution or new
package.

Submit details on rolling back or installing the previous version of the customization.

Provide details about any problems that should be expected while the update is run.
Note: There is no separate section of the PPE that is reserved for validating solutions destined
for just the partner-accessed environment. From a customization validation perspective, a partner
access solution can be validated against the standard PPE environment. Developers may
encounter an issue if they directly parse the user identity (user@UPN.com versus domain/user).
However, if SPUser objects are used, testing can be completed within the existing PPE
environment.
After the customization has been fully validated in PPE, the customer must sign off via e-mail to the TAM
and Microsoft service manager so that Microsoft operations can proceed to deploy the customization in
the production environment according to the change window calendar.
Change Advisory Board (CAB) Production Review
If the Microsoft engineering team and the customer development team approve the customization
deployment for production, the Microsoft engineering team prepares supporting documentation for
submission to the next CAB meeting for production deployment approval. If the CAB rejects the
deployment, deployment is canceled for that change window. Details of the failure are provided to the
customer's development team, and the customer is contacted to begin remediation—first by e-mail and if
necessary with follow-up meetings. After remediation, testing is rescheduled for the next available change
window.
More details about the CAB process are available in the Microsoft Online Services Change Management
Service Description document.
Microsoft Responsibilities
 Test the deployment process and evaluate installation, rollback, and test documentation.

As far as possible, validate the basic functionality of the new customization via the smoke test
(validation test) that is provided by the customer. This may not be possible if a dependency (Web
service, data, or system) is unavailable in the Online Services lab environment.

Review the security of the application for protection against SQL injection, impersonation, and
cross-site scripting.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
27
Important
This review does not constitute the following:

Full security review (which the customer should perform at the design phase).

Handling, transport, or dissemination of any confidential information.

Evaluation of the quality of the error handling and exception handling.
Production Environment Deployment
After the custom solution is approved by the CAB, Microsoft prepares to deploy the solution to the
production environment. This happens during an upcoming change window in the Online Services
production environment. These windows are dedicated deployment windows for tested and approved
customizations, and are usually scheduled for Friday evenings.
All customers receive a change window schedule from their TAM to calculate the work-back dates for
developing a solution, submitting a customization package, and moving the customization package
through the test and review process.
The production environment deployment includes the following:

Installation of the solution packages to the SharePoint Online environment as outlined in the
deployment guide.

Testing the deployment based on the customer-specified validation instructions, to ensure that
the solution successfully deployed.
Important
Deployment does not include any further activities by the Microsoft operations team.
Microsoft does not do any performance or functional testing in the production environment. If the nature of
the customization requires extensive testing after deployment, it is the customer's responsibility to make
resources available to perform this work. If negotiated in advance, a Microsoft operations team member
can be available for the duration of the window to help make minor adjustments to the deployment. When
the deployment window expires, all further updates to the customization that require operational
deployment must be approved through the CAB process.
Microsoft Responsibilities
 Deploy the customization following the customer's installation guidance in the deployment guide.

Test to ensure that the customization is successfully deployed, using the smoke test process that
is provided by the customer.

If the deployment is unsuccessful, roll back the customization following the rollback plan provided
by the customer.

Respond immediately to any customer notification of corruption or problems with a customization.

In the event of a serious problem, during business hours, initiate an emergency CAB meeting if
criteria are met to roll back to the most current version available.
If the customer requires a customization to be rolled back after business hours, a service request
must be opened via the customer's help desk and escalated to the Online Services support team.
Important
There is a risk of loss of content or information if a rollback is required. The customer must notify
Microsoft as quickly as possible, to minimize the loss of content.
Customer Responsibilities
 Make resources available if necessary during the deployment window to test the functionality and
confirm the performance of the customization.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
28

Notify Microsoft as soon as possible about any corruption or problems with the customization.
Re-Drop Policy for the Customization Package
A re-drop is a resubmission by the customer of any part of the customization package that might be able
to keep the same change (deployment) window. The following re-drop policy outlines what is eligible for a
re-drop and under what circumstances a re-drop can occur. The timeframe references are based on the
testing schedule shown in Figure 2.

Re-drop for the same change window will not be possible if the solution is considered so large
that review by day three after the customization package was submitted is not feasible. The
Online Services engineering team provides an assessment of the project size during the HLD
review process.

For small and medium solutions, the Online Services engineering team completes the initial
engineering review by day three after the customization package was submitted. This initial
review includes only the re-drop–eligible testing, as outlined in Table 4 below and in the
installation/uninstall script. If the deployment fails and is delayed, Microsoft does not guarantee
that the initial review will be completed by day three after the customization package was
submitted. Some test steps cannot be performed until the solution successfully deploys.

Only one deployment re-drop is permitted per change window. If the re-drop fails during the
Microsoft engineering team review, deployment of the customization package is postponed until
the next available change window.

Re-dropped code must be delivered to Microsoft by the end of day five after the customization
package was initially submitted and must be validated by CAF again prior to re-drop. If code was
submitted on a Thursday, this is the next Thursday (unless a holiday intervenes).

If deployment, installation, or configuration of the solution fails due to a customer code failure,
Microsoft does not allow a re-drop for the same change window.
If the failure is a problem with the installation script or deployment documents and the affected
documents can be corrected before day five after the customization package was submitted,
Microsoft does permit a re-drop.

When submitting a re-drop, the customer must carefully document the changes that have been
made after the initial drop, and must provide a traceability matrix and a statement of the impact of
the change. The re-drop is a new deployment package validated by the CAF tool, and must
include the entire deployment package with the changes and fixes. If the customer fails to provide
this information, the submission regrettably must be rejected, and deployment is moved to the
next change window.

Microsoft reserves the right to reject a delivery if the design deviates fundamentally from the
approved HLD. An updated HLD document must be submitted to reflect the design change, if the
re-drop modification constitutes a design change.
Table 4 provides additional details about the re-drop policy.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
29
Table 4. Re-Drop Policy by Test Step
Microsoft Test Step
Failed Test Step
Eligible for Re-Drop
Evaluate deployment
Evaluate installation/uninstall script.
Yes
Evaluate deployment guide.
Yes
Determine whether deployment overwrites system files.
Yes
Check for memory leaks
Check object disposal, file handles, connections.
Yes
All code fully trusted
Ensure that all code is listed as fully trusted in Web.config.
Yes
Evaluate cross-site
scripting vulnerabilities
Confirm that all input is properly encoded and code is not
vulnerable to cross-site scripting (XSS).
Yes
Test for SQL injection
Confirm that the input used for SQL queries is not
vulnerable to SQL injection.
Yes
Confirm that CSS/JavaScript/Images/Styles are on hard
disk.
Yes
Confirm that caching is used as appropriate, and cache
invalidated as appropriate.
Yes
Inherit from System.Web.Webpart rather than from
Microsoft.SharePoint.Webpart.
Yes
Verify SQL queries for Enterprise Search.
Yes
All protected methods handle exceptions and log
exceptions to event viewers.
No
Determine whether error
handling and exception
handling are sufficient
Exception handling in Feature receivers is rethrown.
Application writes to custom Event Node <Customer
codename_log>.
Events have unique IDs and specify source, category,
type, and description.
Code falls within
customization policy
Confirm that all customizations are supported within the
customization policy.
No
Elevated privileges
Ensure that best practices are followed for all cases where
elevated privileges are used.
No
Unmanaged code
Ensure that unmanaged code is properly handled.
No
Compatibility with current
version of Office
SharePoint Server
Check to ensure execution within the current production
version of Office SharePoint Server.
No
Best practices
Ensure that code is thread safe.
No
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
30
Online Services Engineering Policies for Custom Solutions
This section describes Microsoft Online Services engineering policies for SharePoint Online Dedicated
custom code deployments.
System Monitoring
Where possible, Microsoft requires that all customizations write to the event log and, if possible, also to
the Unified Logging Service (ULS) log for SharePoint Server. A customization that cannot be monitored
may be deemed unsupportable. The current version of CAF does not validate whether the customization
writes to the event log; however this action is validated via the manual test cases.
If the customization contains the ability to write to the event log to report errors or problems, Microsoft
may configure Microsoft Operations Manager or Microsoft System Center Operations Manager to record
and respond accordingly to the events using alerts. Monitoring configuration occurs during the same
change window as the deployment. If the customization has no ability to write to the event log, this step is
skipped. However, it is critical that the customization provide a means to monitor its health. Without one,
Microsoft is dependent on users reporting problems with the customization, and has no means to assess
or measure the health of the customization.
If Microsoft finds that a customization feature is adversely impacting a core service or service stability,
Microsoft reserves the right to disable the customization, and provide notification to the customer
immediately after stability has been achieved or the core service is back online.
All custom applications from the customer development team must use a custom event node of the form
<customer codename_Log>. In the monitoring section of the deployment guide, provide instructions for
actions that must be taken in the event of errors. Proactive operational monitoring is critical and any
customization-related errors that must be monitored are logged into the event log.
Third-party solutions can log on to the application event logs, but must have unique IDs, and must specify
the source, category, type, and description of the event.
Within the customization package, the deployment guide must include the following information for all
events:

Event type

Event source

Event category

Event ID

Error string

Description of error

Impact of error
In addition, each event must have a troubleshooting article associated with it. For a troubleshooting article
template, see "Appendix G: Troubleshooting Guide Template" later in this document.
Microsoft Responsibilities
 Evaluate the event log that is provided in the customization package, and determine whether
monitoring is possible and necessary.

If a customization adversely affects a core service, disable the customization and notify the
customer.
Customer Responsibilities
 Ensure that the customization writes information to the event log, which will assist with assessing
the health of the customization.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
31

Act quickly when notified that a customization must be disabled or removed due to adverse
impact to a core service or service stability.
Patching Impacts
To ensure the stability and security of Microsoft Online Services, it may be necessary to patch customer
environments. Some updates are both critical and time-sensitive, others are not. Microsoft performs besteffort testing of patches (hotfixes and cumulative updates) or service packs to ensure a smooth
deployment. However, Microsoft does not test patches or service packs against deployed customizations.
Note: It is the customer's responsibility to perform any pre-deployment testing of patches or service
packs against their customizations. Customers can reference the customer-facing build guides or
contact their TAM for the latest patch levels and planned patching for their environment.
Microsoft deploys patches (and service packs to the customer's PPE a minimum of six weeks before the
deployment of the patches or service packs to the production environment. Security patch releases, such
as the monthly security patches, are applied to the PPE and production environment on a shorter release
schedule due to the critical and time-sensitive nature of the patches.
When best practices are followed, customizations rarely need to be modified or touched because of a
patch or service pack.
Microsoft Responsibilities
 Test patches and service packs against the standard hosted environment to confirm that no
problems arise and that the deployment process is successful.

If the update is not critical or time-sensitive, notify the customer at least ten days before the
deployment of any patches or service packs. If the patch is not publicly available, provide a copy
of the patch on demand if the patch is released and being distributed externally.

If an update is critical and time-sensitive, notify the customer as soon as possible before
deployment of the patch.
Customer Responsibilities
 Test customizations against the patch or service pack in the test environments (optional).

Contact Microsoft as soon as possible if any problems related to patches are found.

Except when the problem requires an emergency CAB update sooner than the negotiated
deployment window, provide Microsoft with the necessary update and documentation to mitigate
or prevent the problem when the patch or service pack is applied. To view the criteria for an
emergency CAB meeting, see "Break-Fix Remediation" later in this section.
Updating a Customization
When a customer provides an update to a customization that is deployed in the production environment,
the customer should follow the steps described in "Timeline Overview of Customization Process" earlier in
this document. Some steps are completed more quickly when minimal code changes have been made.
When the customer submits an update to a customization or its documentation, it is very important to
highlight in the deployment guide what is changed and to provide details about the uninstall or rollback
process to the previous version. It is also important to call out any problems that might be expected with
the update.
Microsoft Responsibility
 Determine whether the validation process can be completed more quickly than the normal 10
days.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
32
Customer Responsibilities
 Provide complete documentation, as specified in "Updating Existing Custom Code" earlier in this
document.

Understand that the Microsoft engineering team will take the update through the entire validation
process, although that process may be a bit shorter for an update than for a new customization.
Break-Fix Remediation
Break-fix remediation addresses what happens if a critical problem is found with a customization that is
deployed within the production environment—whether the problem occurs immediately after deploying the
customization, or some time later.
These are the immediate options that are available to customers:

Retract the solution.

Roll the solution back to the previous production version.

Wait until a custom code fix can be deployed. Microsoft makes every effort to accelerate the
testing of the fix, but does not provide a specific shortened SLA.
If remediation of the issue is required, it is generally handled in the same manner as other changes made
to the production environment, as directed by the change management process. All efforts are made to
perform remediation as quickly as possible, but the change cannot be made until the first available
negotiated change (deployment) window that occurs after the break-fix solution remediation is complete.
Important
No changes will be accepted to the deployment documentation after the customer has signed off on
PPE validation. The customer will need to reschedule the deployment date to the following change
window, if any further changes to the customization are identified.
For a detailed description of the process to escalate post-deployment issues that are related to
customizations, see "Appendix L: Process to Escalate Customization Post-Deployment Issues" later in
this document.
Emergency Change Remediation
If a critical problem meets the Microsoft emergency change criteria, the remediation is accelerated by
Microsoft to address the situation as quickly as possible. Emergency deployments are not restricted to a
scheduled window, and all effort is made to negotiate the window between Microsoft and the customer.
Emergency change criteria for a broken customization are defined as follows for a break-fix situation. One
or more of the following criteria must be met:

Causes a significant and quantifiable business impact.

Impacts availability or system stability.

Puts information or the security of content at risk.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
33
Important
The following are not emergency change criteria:
o
Errors that affect the visual presentation of data.
o
Errors that affect the display of content from a third-party solution.
o
A customization that doesn't work as expected but doesn't meet the emergency change
criteria.
If the problem does not meet the emergency change criteria, the change must be submitted like any other
update through the regular customization process.
Within 24 hours of receipt of the emergency customization package, Microsoft responds with the time
required to deploy the code to production. The time that is required depends on both the complexity of the
code and the risk to the service.
The customer should escalate a service-impacting situation caused by a customization to the Microsoft
Online Services support team, with a joint troubleshooting session if the root cause is unknown. A change
request (CR) may follow if a code update is required. If the service is not impacted and the solution is
known, then customer must fill out a High Priority CR after the solution is fixed and fully tested on
premises.
If custom code has an adverse impact on the Online Services customer experience, or impacts the ability
of Microsoft to meet its SLA for performance, stability, and availability to clients, it will be necessary to
take immediate action. This may include debugging the application and optimizing it for current load and
stress conditions, or removing the code from the environment to return to a stable state. If one of these
situations occurs, an emergency CAB meeting is called, and the customer is consulted to make the best
decision possible.
Important
The SLA is suspended for any downtime that is incurred during emergency change deployment.
Microsoft Responsibilities
 Respond within 24 hours when notified by a customer of a problem within the environment.

If the problem meets one of the emergency change criteria, take the request to the emergency
CAB.

Validate the proposed change as quickly as possible.
Customer Responsibilities
 Notify Microsoft as soon as possible via a service request (SR) when a problem is encountered.

If necessary, build an update to address the problem, and provide adequate documentation for
Microsoft to install, smoke test, and roll back.

Be ready to validate the change immediately after the remediation deployment notification is sent.
Impact of SharePoint Online Upgrade on Customizations
Microsoft Online Services has committed to providing customers with the most recent version of Office
SharePoint Server. This means that at some point, Microsoft will upgrade the current Office SharePoint
Server version that is used for SharePoint Online to the next release. The customization upgrade process
is the same as the customization validation process, with the exception that in the upgrade process there
are no HLD reviews. Customers will receive upgrade guidance documentation regarding specific dates at
least four months before their upgrade date.
The upgrade process is documented in Figure 3.
Note: The upgrade processes documented here may change for future releases.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
34
Figure 3. Online Services upgrade to new version of Office SharePoint Server
Microsoft Online Services will provide customers with access to the upgraded SharePoint Online preproduction environment 11 weeks before the customer's environment will be upgraded. The 11-week
timeframe before upgrade consists of two periods: a 9-week validation of the PPE environment and a 2week user acceptance testing of the production environment. During the 9-week PPE validation, the
customer will get three code drops. The customer needs to deploy at minimum a third of the upgraded
customizations in the first code drop. After the PPE validations, the customer will have a 2-week period to
do user acceptance testing against the production farm.
Important
The PPE is only for user acceptance testing and verification. All customizations must be fully tested in
the customer's QA environment prior to PPE deployment. Prior to using the PPR, the customer must
document any open known issues in the deployment guide.
The upgrade schedule is shown in Table 5, with the Microsoft operations team responsibilities and
customer responsibilities clearly defined.
Table 5. Schedule for Upgrade to Next Version of Office SharePoint Server
Week
Activity
16
Generate inventory and CAF reports
16
Upgrade dev and test environments
15
Deliver reports to customer
15-11
Upgrade impacted customizations
Microsoft
Operations
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
Customer




35
Week
Activity
Microsoft
Operations
Customer
11
Build PPE

11-10
Validate batch 1

9
PPE installation of batch 1

9
PPE customization validation
9-8
Validate batch 2

7
PPE installation of batch 2

7
PPE customization validation
7-6
Validate batch 3

5
PPE installation of batch 3

5
PPE customization validation

4
Complete verification in PPE

3-2
Production and disaster recovery deployment
1
Final upgrade user acceptance testing
1
New HLD documents accepted

0
Upgrade event






Microsoft expects the customer to provide the necessary resources to adequately review the
customizations and confirm full functionality. It is the customer's responsibility to make any changes
necessary for the code to work after the migration, following the standard Microsoft review and
documentation process.
This structured approach to SharePoint Online upgrades is designed to provide a seamless migration
process. If Microsoft discovers any customization that it feels will be difficult to migrate, this will be called
out in a customization inventory report and provided to the customer.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
36
Service Policies
Service policies define the customization types by which SharePoint Online Dedicated can be modified.
Supported customization types are shown in Table 6. If a customization type is not listed, it might still be
supported; contact the TAM for clarification.
Table 6. Supported Customization Types
Customization Type
Supported
Comment
Custom-managed path
No
Microsoft Online Services does not support custom-managed
paths used for self-site creation (users creating their own site
collections through the SharePoint interface).
SharePoint database schema
change
No
Changes directly to the database schema are not
supportable.
SharePoint database data access
No
No access is provisioned directly to the SharePoint
databases. All access to the databases is via the object
model (OM) or Web services.
Modify built-in SharePoint files
No
Online Services does not support any changes to the
SharePoint files on the file system. This includes shipped site
definitions.
Web services access
Yes
All Web services that ship with Office SharePoint Server are
exposed.
Office SharePoint Designer editing
Yes
Any changes that can be made with Office SharePoint
Designer are supported.
Change mapped host name after
deployment
No
Online Services does not support the changing of the hosted
domain name—for example, sharepoint.contoso.com—after
the environment has been deployed. The customer should
carefully choose the host name of its environment before
service adoption.
Visual Studio installed on
deployment
No
Online Services does not allow Visual Studio to be installed
on a Web front-end (WFE) server for troubleshooting.
Install Microsoft Office client on
server
No
Online Services does not allow Microsoft Office clients to be
installed on a WFE server.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
37
Supported Customizations Policy
Table 7 describes the various types of SharePoint customizations that are possible and which are
supported within the Microsoft Online Services environment. Non-supported types are either planned for
a later release of Online Services solutions or have been determined at this time to pose a risk to the
environment, add additional operational overhead, or be potentially difficult to upgrade to future versions
of SharePoint Online Dedicated.
Table 7. Supported Customization Types
Customization
Type
Supported
Comment
SharePoint Features
Yes
Office SharePoint Server Features are server-side customizations at the file
system level. They can contain modular items that can be installed and
activated in a SharePoint Online environment.
Feature stapling
Yes
Feature stapling, also known as Feature site template associations, is the
ability for a Feature to be attached to all new instances of sites that use a
given site definition, without modifying the site definition or creating code
routines to activate the feature on each site.
Feature event
receiver
Yes
A Feature event receiver, or Feature receiver, is a server-side code routine
that is called as part of certain key events in the lifetime of a Feature, such
as installation, activation, deactivation, or removal.
Windows Server®
service
No
The Windows Server service is installed on the server to perform major
actions. It runs in a separate process space from the Office SharePoint
Server instance. A service has a relatively high cost for deployment and
manageability.
Timer job
Yes
A timer job is a built-in Office SharePoint Server object structure that can
perform various tasks within the SharePoint Online environment on a
scheduled or one-time event basis. Timer jobs pose a risk for system
performance and stability.
Scheduled task
Yes
A scheduled task permits the running of code on the Windows-based server
on a defined schedule. On event occurrence, the code is run. Scheduled
tasks run outside of Office SharePoint Server. There is no trigger from
within Office SharePoint Server.
Web application
No
A Web application is code or content installed in a new Web application
directory, or as a subdirectory under an existing Web application. It provides
functionality that SharePoint does not. Additional Web applications pose an
additional support burden on the Microsoft operations team.
Web service
Yes
A Web service is server-side code that exposes code routines to be called
from remote systems.
Site definition
No
A site definition is a server-side collection of files that defines the structure
of one or more site templates. When a site is created with a custom site
definition, it is dependent on that site definition in the future, including when
upgrading to a new version of Office SharePoint Server.
List definition
Yes
A list definition provides the schema for an Office SharePoint Server list.
Site template
Yes
A site template is a package that contains a customized site design based
on an existing site definition.
List template
Yes
A list template is a package that contains a set of customizations from a
base list structure. A list template should not be confused with a list
definition.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
38
Customization
Type
Supported
Comment
Field type
Yes
A field type is an extensible method for allowing new common data
structures within Office SharePoint Server for use in lists or other locations
that can use SPField objects.
Content type
Yes
A content type is a reusable collection of settings that can be applied to a
certain category of content. Content types enable the management of
metadata and behaviors of a document, item, or folder type in a centralized,
reusable way.
Column template
(column definition)
Yes
A site column, also known as a field, is a reusable column definition, or
template, that can be assigned to multiple lists across multiple SharePoint
sites. Site columns decrease duplication of work and help ensure
consistency of metadata across sites and lists.
Delegate control
Yes
Delegate controls allow certain predefined elements pieces of the
SharePoint environment to be replaced (like a field control) by other controls
through Office SharePoint Server Features.
Form template
Yes
Form templates are user-control–based (ASCX-based) control templates
that bring together multiple controls into a nested structure, where each
control consists of templates and can be used to richly extend list item
forms.
Custom action
Yes
Custom actions are items (commands) that are added to menus or toolbars
through the use of Features.
_layouts page
Yes
A _layouts page is any page stored in the _layouts virtual directory
within Office SharePoint Server.
Event handler
Yes
An event handler is a server-side code routine that is called when registered
events occur within the SharePoint environment. Custom event handlers
can be attached to and have a scope of Web application, site collection,
Web, list, or document library.
Backward-compatible
event handler
Yes
A backward-compatible event handler is a server-side code routine that is
called when a registered event occurs within an Office SharePoint Server
document library. Backward-compatible event handlers can be attached to
and have a scope of a document library only.
Coded workflow
Yes
Coded workflows are Windows Workflow Foundation workflows that
reference an assembly for the workflow pipeline.
No-code workflow
(declarative workflow)
Yes
No-code workflows, also known as declarative workflows, are sequential
workflow pipelines that are configured on a list or document library. They
require no installation of server-side code.
Workflow activity
Yes
Workflow activities are compiled classes that are used as a part of the
modular steps in a workflow. An activity is used as part of a workflow action
that will be run. Workflow activities run as server-side code when used as
activities within the SharePoint environment.
Solutions that
customize or change
the Central
Administration Web
application
No
Central Administration (CA) is currently not provisioned on all farm Web
front-end (WFE) servers as a best practice. In case a customer custom
solution is deployed to CA, it is deployed only to the machines where CA is
provisioned.
This results in a situation where, if there is the need to provision a new CA
on a different server on the farm, the custom solution is not deployed to the
new server. This causes the features using the solution to malfunction.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
39
Customization
Type
Supported
Comment
Workflow condition
Yes
Workflow conditions are compiled classes that are used as a part of the
modular steps in a workflow. A condition is used to determine when a
workflow action will be run. Workflow conditions run as server-side code
when used as conditions within the SharePoint environment.
Web Part
Yes
A Web Part is a modular component that is used within the SharePoint
environment to perform activities or display information.
SharePoint theme
Yes
Office SharePoint Server themes are collections of graphics and cascading
style sheets that can modify how a Web site looks.
Document icon
Yes
Document icons are the graphical items that are used to represent
documents that are exposed within document libraries. Each preconfigured
document type in SharePoint has a corresponding document icon entry in a
server configuration file, but other file formats may lack appropriate icons.
iFilter or protocol
handler
Yes
An iFilter is a server-side component that is used by the indexing system to
index documents that are identified as having a file format that is associated
with the iFilter. Custom iFilters require deployment to all servers in the
environment that do indexing; they also require changes to mapped
properties for search.
A protocol handler enables indexing applications like Office SharePoint
Server to systematically crawl the nodes of a data store to extract relevant
information to include in the index. Each protocol handler is used to index a
specific type of data store.
Document converter
No
A document converter is a custom executable file that takes a document of
one file type, and generates a copy of that file in another file type.
Information
management policy
Yes
An information management policy is a set of rules for a certain type of
important content. Policy enables administrators to control and evaluate
who can access the information, how long to retain information, and how
effectively people are complying with the policy itself.
Business Data
Catalog (BDC)
definition
Yes
A BDC definition is an XML file that defines the structures used by the BDC.
BDC
(GenericInvoker)
Yes
Customers can use the GenericInvoker property of a BDC entity definition to
write back to a data source.
BDC-based search
crawl
No
Search crawls based on a BDC definition are not supported. Properties
associated with a user profile will be indexable and displayed within People
Search.
Excel user-defined
function (UDF)
Yes
User-defined functions (UDFs) are server-side managed code, run by
Microsoft Office Excel® Calculation Services to provide capabilities not
included in the base product. These include:
Functions that are not built into Office Excel.
Custom implementations to built-in functions.
Custom data feeds for legacy or unsupported data sources.
Application-specific data flows.
InfoPath Forms
Services custom code
Yes
Microsoft Office InfoPath® Forms Services custom code is uploaded and
hosted by the server-side Office InfoPath Forms Services.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
40
Customization
Type
Supported
Comment
InfoPath form view
control
Yes
An Office InfoPath form view control is a server-side Office InfoPath Forms
Services viewer control can display a Web browser view of an Office
InfoPath form.
HTTP handler
No
HTTP handlers are used to handle file requests within the ASP.NET 2.0
framework. For example, within ASP. NET 2.0 and Office SharePoint Server
2007, ASPX page requests and ASMX Web service requests are served by
HTTP handlers.
HTTP module
Yes
HTTP modules are classes that handle runtime events in ASP.NET 2.0 and
Office SharePoint Server 2007.
Pluggable
authentication
provider
No
A pluggable authentication provider is a module used by ASP.NET 2.0 and
Office SharePoint Server to replace the built-in authentication providers.
Custom modules require a high level of testing to help ensure security.
Pluggable single signon provider
No
A pluggable single sign-on provider is a modular component that can be
used to handle the storage and mapping of credentials for use in connecting
with third-party or back-end systems. This customization type requires a
high level of security review and scrutiny.
STSADM command
extension
Yes
A custom STSADM command extension is server-side code that allows the
Stsadm utility to have new commands available to run from the command
line.
Inline code
No
Inline code is server-side code that is directly embedded into a Web page.
Inline code has a high level of risk compared to compiled assemblies.
Web.config settings
change
Yes
The Web.config file controls most settings for the ASP.NET environment
that Office SharePoint Server 2007 is built on. Typically these controls are
modified as a part of a solution.
Changes must be implemented using a Feature receiver so that they will be
automatically populated on all the WFE servers. Manual modification of the
Web.config settings is not supported.
Security policy
Yes
A custom security policy grants code access security (CAS) rights to certain
server-side code components that run under a specific Web application
context.
COM server
No
A Component Object Model (COM) server is an unmanaged library that
typically runs on a server with full permissions. COM objects typically
perform poorly when interops are set up between the COM object and .NET
code.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
41
Appendix A: SharePoint Developer Resources
This appendix offers links to content that may be useful to developers of custom code for SharePoint
Online Dedicated. It also presents a discussion of best practices for developers.
Getting Started

SharePoint Developer Center
Primary MSDN site for SharePoint developers.

Office SharePoint Server - TechNet site
Articles and blogs about Office SharePoint Server that are submitted and rated by the general
community.

Best Practices Resource Center for Office SharePoint Server 2007 - TechNet site
Best practices as outlined by the Office SharePoint Server product team and Microsoft Consulting
Services.

Finding Developer Help for SharePoint Products and Technologies - MSDN article
An introduction to where to find SDKs, peer-to-peer forums, MSDN developer centers, and Microsoft
TechNet resources that can be helpful for developing with Office SharePoint Server products and
technologies.

"Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0"
An MSDN article that discusses the differences between Windows SharePoint Services and
traditional ASP.NET development (in two parts).

o
Part 1 of 2
o
Part 2 of 2
Working with ASP.NET 2.0 Web Parts and Windows SharePoint Services 3.0 - MSDN article
Best practices for deploying custom Web Parts to SharePoint sites.

An In-Depth Look at Windows SharePoint Services and Office SharePoint Server 2007 (Level 200)
A TechNet webcast by Arpan Shah (91 minutes).

Getting Started with SharePoint Development - MSDN blog
Helpful information and blog discussions by a Microsoft technical product manager for the Office
SharePoint Server Developer Platform.

Writing to the Trace Log - MSDN reference
Sample code that demonstrates how to write to the trace log, including calls to unmanaged code. If
writing to the trace logs, ensure that it adheres to this publicly available documentation.
Webcasts
The Microsoft Events and Webcasts site offers a series of useful SharePoint webcasts created for MSDN
about development on Office SharePoint Server:
o
Application Development
o
Collaborative Solutions
o
Content Management
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
42
o
Overview
o
Portals and Search
o
SharePoint Internet Business
o
Workflow
More Development Resources

Best Practices: Common Coding Issues When Using the SharePoint Object Model - MSDN article
Common issues encountered by developers who write custom code by using the Office SharePoint
Server object model (updated April 2009).

Best Practices: Using Disposable Windows SharePoint Services Objects - MSDN article
Appropriate ways to write code using Windows SharePoint Services objects to avoid retaining objects
in memory. There is also a section near the end of this article that talks more about disposing objects.
The article was recently refreshed to reference the SPDisposeCheck tool.

Common Page and Site Customization Tasks - MSDN reference
Step-by-step procedures for common page and site customization tasks from SDK.

Silverlight Blueprint for SharePoint - MSDN Channel9
Guidance about how to use Microsoft Silverlight™ 2 with Office SharePoint Server.

Microsoft Office Interactive Developer Map Version 2 - Office Developer Center download
Introduction to interactive mapping of development features to resource material.

SharePoint Guidance - MSDN Patterns and Practices
A demo and guidance for common topics such as unit testing, debugging, packaging and
deployment, setting up a team development environment, solution maintenance and upgrade, and
how and when to use Office SharePoint Designer.

Approaches to Creating Master Pages and Page Layouts in Office SharePoint Server 2007 - MSDN
article
Two ways to create ASP.NET 2.0 master pages that define a site's global appearance, and how to
create page layouts that define the rendering of specific content pages.
E-Learning Resources

Microsoft Office SharePoint Server 2007 Training Portal
The main portal for all SharePoint related e-learning materials published by Microsoft.
Best Practices for SharePoint Developers
The following are best practices that have been developed by Microsoft for custom SharePoint solution
development.
Best Practices for Development Environments

Replicate the SharePoint Online environment. The SharePoint Online team creates SQL and
SharePoint build guides that describe the build settings and product versions used in the SharePoint
Online Production environment, and help customers build their local lab and test environments.
Customers can request the build guides from their TAMs. By using these guides the customers can
create development and test environments that mimic the actual SharePoint Online environment.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
43

Configure development environment as a one-way trust. Note that the SharePoint Online
environment is configured to use Secure Sockets Layer (SSL), and that the SharePoint Online
service is accessed using a fully qualified domain name (FQDN). In addition to this, the Active
Directory® service is implemented to use a one-way trust. To validate the customizations—especially
the line-of-business systems—be sure to configure the development environment so that a one-way
trust is in place.
Development Environment Software Best Practices

Ensure a complete software installation. In the case where a development environment will have
everything installed on the same server, Table 8 shows the software that is typically installed.
Table 8: Developer Server Software
Software
Requirements
Windows components
IIS, SMTP
Microsoft .NET
Framework
Version 3.5 SP1
Source control client
Team Foundation Server (recommended)
Visual Studio 2008
Visual Studio 2008 extensions for Windows SharePoint Services 3.0
Microsoft Office system
Office SharePoint Designer
Microsoft Office Word, Office Outlook®, Office Excel, Office PowerPoint®, Office Access®
Software development
kits (SDKs)
Office SharePoint Server 2007 SDK
Office SharePoint
Server 2007
Standard or Enterprise
Microsoft SQL Server®
2005 or SQL Server
2008
With latest service pack
Browsers
Windows Internet Explorer® 7.0 or Internet Explorer 8.0
Windows SharePoint Services 3.0 SDK
Mozilla Firefox
Opera
Apple Safari – Windows Version


Assemble appropriate aids. Developers should also have the following development aids available:

Microsoft Internet Explorer Developer Toolbar

Team Foundation Server for source control and build automation

.NET Reflector for analyzing .NET assemblies

Fiddler Web debugging proxy

WSPBuilder SharePoint solution package (WSP) creation tool

STSDEV development tools

U2U CAML Query Builder

SPDisposeCheck SharePoint Dispose Checker Tool
Integrate FxCop into the build process. Even though the CAF application validates solutions using
FxCop and other tools, it can be beneficial to integrate these tools as a part of the actual build
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
44
process. For more information, see FAQ: How do I run FxCop during a post-build event? from the
Visual Studio Code Analysis team blog.

Integrate each developer's environment. Developers work within their own environment and use
source control to share and integrate their work. Keep in mind that each developer on a team needs
an environment similar to the configuration outlined in Table 7. A separate integration environment
should also be maintained for formal daily builds. With a product like Visual Studio Team Foundation
Server, an automated build process can be established where the checked-in code is compiled and
deployed (usually scripted) to the central development server. For additional best practices in this
area, see Team-Based Development in Microsoft Office SharePoint Server 2007.
Automate Source Control and Build Process
Whether a project includes one or many developers, source control is very important for Office
SharePoint Server. Office SharePoint Server doesn't support version control or "versioning", so
management of the source and build process is vital for a successful project. Microsoft recommends
Team Foundation Server for source control and build automation. Tools like WSPBuilder can greatly
assist in the build process for the customer's solutions.
Do Not Attempt Solution Versioning
Versioning custom solutions—that is, maintaining version control over them—is not realistic. Each
solution must have a unique name. It is possible to create a unique name for each new version of a
solution as it is deployed. However, the contents of the solution can easily overwrite data from a previous
version. When there is an overlap in data (DLL, for example), removing the solution causes the data to be
removed from the system. All solutions with those common elements then fail to work. Any versioning
effort results in a much more complicated support path.
Use Proper Namespaces for Customizations
Each feature of a SharePoint customization is deployed to the Web front-end (WFE) servers file system,
into a folder corresponding to the feature name. In order to minimize the risk of having two features
overwriting each other's files, we recommend that the features be named with a proper namespace. For
instance, instead of calling the feature Contract, call it HR.Contract.
Avoid Feature Versioning
Although features can be deployed on specific site collections on a SharePoint Online farm, as with
solution versioning, the only way that a development team can version features is to name each feature
differently—even features with the same code base. There will seldom be a need to install multiple
versions of a feature within the same solution. It's much more likely that newer versions of a solution will
contain newly added features―and this doesn't require versioning. It's best not to attempt to have
multiple versions on the same farm, primarily because of support issues.
Use as Little Code as Possible in Application Development
. The less code that the development team needs to write, the fewer bugs are introduced into the system.
Also the quicker an application can be fixed and re-installed, the less downtime a system will experience.
Sharing common code is conducive to this goal. Common code reduces the code footprint.
Each solution should have as little code as possible. Having several solutions per "application" makes for
better and safer rapid deployment scenarios. Web sites are active, constantly evolving environments.
There is a certain amount of risk with deploying an application, but if the application has many installable
components, it becomes safer to test and install one of the components, instead of having all of the
components packaged as a single solution. This means breaking down the installation of an application
into smaller pieces, and the administrator who runs the installation must make decisions about which
specific pieces to update.
Internally at Microsoft, a simplified installation process is used to install a single batch file--), which
includes all the solutions and applications dependencies with each deployment folder--so that the
Microsoft operations team can open up and examine to see what will be happening.. The batch file is very
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
45
configurable and allows for specifying which components to install, in keeping with the strategy
highlighted above.
When developing an online solution, Microsoft uses Visual Studio Team Foundation Server for building
the solution. The solution that is created is simply a series of batch files. Both 32-bit and 64-bit copies of
each solution are built. The Office SharePoint Server binaries have the same references, regardless of
whether it's 32 or 64-bit, so building a copy directly on a 64-bit machine is not necessary.
Plan Carefully when Installing Dependencies
Solutions have configuration and application dependencies. Dependencies are not always
straightforward, nor are they static over the course of development or even over the life cycle of the code
in production.
Some dependencies are used by multiple applications. This is where the discussion of "versioning"
becomes important. Because versioning is not encouraged, it's important to keep as little code as
possible on the system. Almost every application that is deployed will have at least some commonality
with other applications. Breaking the solution into smaller deployable units is preferred, so this means that
there are many more solutions that have dependencies on one another.
Driven by a build environment, all dependencies are kept within an output folder for each application
project. This is the only guaranteed way to know the dependences for each project. For testing, this is the
difference between being 100-percent certain that the latest binaries were installed and being 90-percent
sure. When the dependencies are not included in the output folder, this becomes a tedious manual step:
to first install dependencies (from some build number, typically communicated in an e-mail message), and
then to install the applications.
The customer test team should deploy their solutions in the same manner that the Online Services
operations team would deploy the application. Because the test team also wants to be 100-percent
certain that all of the latest dependencies on each deployment are included, it's best not to allow anything
to change, and to eliminate manual steps. Again, if the dependencies are not kept together in a separate
folder, there is not a 100-percent certainty that the version will be correct during installation. It's very easy
to grab a mismatched solution, and then have it take hours or even days to realize the mistake.
Many product groups handle common dependencies by building and dropping all applications into one
folder structure. SharePoint Online development teams for Microsoft use a very iterative deployment
cycle, and build only the specific feature being worked on. With this common code the same type of risk
exists, but on a less significant scale. It is possible for common code to break dependent solutions that
are not in the current build. The test team must identify and verify these issues.
One negative aspect of having dependencies in the application output folder instead of a common folder
is that it becomes harder for the Microsoft operations team to manage that dependency. However, having
a common output folder for commonly used dependencies provides a false sense of security, because
actually any solution or feature can modify attributes and assemblies in any other feature without warning.
The Microsoft operations team must rely on the customer’s development team's naming convention to
know what is happening. It's possible that the development team could accidentally install a feature over
another feature of the same name, but that's what the customer test team should be catching. The test
team has validated the solution by the time it gets to production, so the expectation is that no errors will
be found in the mirror and production environments.
Limit the Number of Solution Packages in a Customization
When a Microsoft operations team is managing the deployment of a solution to SharePoint Online, having
a large number of solution packages that need to be tracked and managed poses a challenge. The more
solution packages in a customization, the greater the possibility that something will not be installed
correctly, the longer the solution will take to deploy, and the easier it is to mix incompatible versions of
solution packages. Microsoft recommends that customers scrutinize their deployment plans and keep the
number of solution packages to the minimum number possible needed for the project. Keep in mind that a
solution package can contain several features, so there is no necessity to have one solution package for
each feature.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
46
Do Not Use ADO.NET to Connect to Databases
SharePoint Online does not support the use of ADO.NET to connect to databases that are not hosted by
Microsoft Online Services. Microsoft supports connectivity via service-oriented architecture (Web
services). We recommend that, where possible, developers consider using a Windows Communication
Foundation (WCF) application instead of just a SOAP-based service. For more information, see the
following references:

Guidelines and Best Practices for creating Communication Foundation applications (MSDN
article)

Walkthrough: Creating a Custom Web Service (MSDN article)

Creating a Custom Web Service for SharePoint ("Toolbox for IT" blog)
Best Practices for Developing Code that Connects to an Internet Address
Microsoft Online Services has observed slow crawl times for customer development teams that are
writing code or using components that connect to Internet URLs. Examples are stock feeds, RSS feeds,
or JavaScript elements from remote services like Google Analytics.
The Office SharePoint Server index server that performs search crawling does not have Internet
connectivity outbound from the Microsoft data center. This lack of Internet connectivity impacts page
rendering because the page waits for the connection request to time out before finishing.
We recommend that developers write their code using an asynchronous call system such as AJAX. AJAX
is JavaScript that is downloaded by the index server but is not run. It is also best if the index server does
not attempt to connect to the Internet. These steps ensure that crawl times are not impacted by the
customer's customization.
Best Practices for Increasing SharePoint Site Performance
Performance is usually a high priority for any Web site deployment, including SharePoint site
deployments. Developers who are writing code and deploying code for SharePoint sites with even
moderate traffic should consider using the PortalSiteMapProvider for increased performance. The
following Microsoft developer blog provides guidance on how to use it:

Increased Performance for MOSS Apps Using the PortalSiteMapProvider (in the Microsoft
Enterprise Content Management (ECM) team blog)
Another useful resource on the use of the CrossListQueryCache object, which is built on top of the object
cache / PortalSiteMapProvider:

CrossListQueryCache Class (MSDN reference)
Configuring Caching
All customizations should leverage the appropriate caching mechanisms. For example, the home pages
of any portals or other frequently read sites must be configured to use output caching.
The Output caching feature can be used on a site (or site collection) only if the Office SharePoint Server
Publishing feature is activated for the site. For more information, see the Microsoft TechNet article
Caching in Office SharePoint Server 2007.
Using Content by Query Web Part Objects
Whenever using Content by Query Web Part objects, ensure that they are scoped properly. For example,
if the customer must retrieve information from just one site, or from one list in a site collection, it is much
less resource-intensive to configure the Web Part to read only that site or list instead of having it
enumerate through the entire site collection.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
47
Customers should archive content that is not necessary and may be inadvertently considered in the
scope of Content by Query Web Part. For more information, see the Microsoft TechNet article Additional
performance and capacity planning factors (Office SharePoint Server).
Removing Unused Web Parts from SharePoint Pages
If the customer does not need a Web Part to be present on a Web page, the customer should remove it
from the page rather than closing it. Closed Web Parts are still part of the page rendering process,
although they will not show anything. The customer should also check the Advanced Web Part gallery
and options link to verify whether the customer has any parts in the Closed Web Parts collection.
Configuration Management
Two mechanisms can be used when changing SharePoint configuration information: Web.config
modifications and SharePoint configuration modifications.
Web.config modifications are any changes to this file. SharePoint configuration modification includes
changes to search settings (scopes, managed properties), audience information, and other settings that
are typically accessed via either the Central Administration or the SSP management pages.
Customizations that must change these settings must be implemented using Feature receivers. The
Feature receivers can use the appropriate SharePoint APIs to update both Web.config and the
SharePoint settings. Microsoft reserves the right to reject any customizations that are implemented as
applications that need to be manually run by the Microsoft operations team.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
48
Appendix B: Testing Resources
SharePoint Online testing resources and testing best practices are identified in this appendix. It also
presents a discussion of best practices for testers.
Online Resources

Checklist for Testing SharePoint Web Parts
2003 checklist that largely still applies.

Testing Your Web Applications for Cross-Site Scripting Vulnerabilities
Recommendations on how to handle testing XSS vulnerabilities.
Load Testing and Performance Resources

Load-Testing Web Applications (MSDN Patterns and Practices)
General introduction about how to load-test a Web application.

SharePoint Test Data Load Tool
Details about the WSSDW.exe test data load tool.

Tools for performance and capacity planning (Office SharePoint Server)
Details about the WSSDW.exe test data load tool.

Load Testing SharePoint 2007 Sites and Applications using Visual Studio 2008 Tester Edition
Webcast about using Visual Studio 2008 Tester Edition to scale Office SharePoint Server 2007 sites
and applications.

Effective Web and Load Testing in Visual Studio Team System (Level 200)
Webcast developer session about using Visual Studio Team System to load-test Web applications.

Performance and Capacity Planning Resource Center for SharePoint Server 2007
Published resources about performance and capacity planning for SharePoint Online.

Caching in Office SharePoint Server 2007
Information about output caching, object caching, and caching for binary large objects (BLOBs).

Estimate performance and capacity requirements for portal collaboration environments
A usage profile example for load testing purposes.

Working with Large Lists in Office SharePoint Server 2007 (white paper)
Guidance about strategies for working with large lists hosted within SharePoint Online.
Note: The customer will be prompted to download a Word document.

How to integrate SP Dispose Check into Visual Studio Solutions
A blog entry that outlines the steps necessary to integrate SP Dispose Check into the integrated
Visual Studio runtime environment.
Best Practices for Testing
The following best practices for the testing process are used by the Microsoft Online Services internal
development teams.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
49
Scope of Testing

Do not limit testing to just what has changed. Regressions in the code can impact seemingly
unrelated portions of the customization. We recommend full test passes, even for small updates.
Ultimately, the extent of testing is at the customer's discretion.

The secret to success with testing against Office SharePoint Server is to adhere to a process and
stay with an agile methodology as closely as possible. (For an overview of agile methodology,
see the Agile Modeling site at www.agilemodeling.com/.)
Microsoft Testing of Custom Solutions
When presented with code from customers, Microsoft performs the following tests:

64 bit machines are required for appropriate testing of all customizations.

Check for memory leaks.

o
Check for object disposal.
o
Avoid making use of Microsoft Win32® application programming interfaces (unmanaged
code).
o
Verify that file handles are closed.
o
Verify that connections are closed.
o
Tool: CAF
o
Tool: .NET Reflector
Determine whether the error and exception handling have been sufficiently done.
o
Verify that all the protected methods can handle exceptions, and log exceptions to event
viewer.
o
Verify that exception handling in the Feature receivers is rethrown; if not, the Feature is only
partially activated.
o
Verify that all custom applications from the customer use a custom event node, of the form
<Customer codename_Log>.
o
Verify that any generated application event logs (in-house code or third-party) have unique
IDs and include source, category, type, and description.

Walk through the code to determine whether all customizations fall within the scope of the
customization policy presented in this document.

Evaluate all cases where elevated privileges are requested by the code.

o
Reference: Running Commands with Elevated Privileges in Windows SharePoint Services
3.0
o
Reference: Best Practices for Using Elevated Privileges and Impersonation in SharePoint
Services (Note: This is Mindsharp premium content: the customer must register at the
Mindsharp login page to gain access.)
Verify that all code is fully trusted.
o

Confirm that all code is registered within Web.config as fully trusted.
Verify that unmanaged code is handled properly.
o
Verify a smart location of the interop boundary to promote performance.
o
Verify the use of abstraction or batching layers as appropriate.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
50


Use of an interoperability technology (P\Invoke, C++/CLI, COM) that matches the code.
o
Reference: Managed and Native Code Interoperability: Best Practices (Note: This may take
some time to load.)
o
Reference: CLR Inside Out: Introduction to COM Interop
o
Reference: CLR Inside Out: Marshalling between Managed and Unmanaged Code
Evaluate deployment.
o
Determine whether the deployment overwrites any system files (pre-existing Office
SharePoint Server 2007 files on the file system).
o
Verify that every release has an installation script.
o
Verify that the solution can be removed, added to, or upgraded when it is run multiple times.
o
Verify that uninstall scripts are provided to roll back to previous version.

Verify that the code runs correctly against the current production version of SharePoint Online.

Evaluate cross-site scripting vulnerabilities for all data input.

o
Make sure to use Server.HtmlEncode.
o
Test using scripts provided at the MSDN reference site Testing Your Web Applications for
Cross-Site Scripting Vulnerabilities.
o
Reference: How To: Protect from Injection Attacks in ASP.NET
Test for SQL injection, especially if a custom database is used.
o

Test for security vulnerabilities.
o

Reference: How To: Protect from SQL Injection in ASP.NET.
Microsoft Code Analysis Tool .NET (CAT.NET) is a binary code analysis tool that helps
identify common variants of prevailing vulnerabilities that can give rise to common attack
vectors like cross-site scripting (XSS), SQL injection, and XPath injection.
Best practices (recommended, but not a basis for solution rejection):
o
CSS, JavaScript, images, and styles should be on the hard disk, to use IIS compression
(GZip).
o
Caching should be used appropriately, invalidating the cache as appropriate.
o
Inherit from System.Web.Webpart rather than from Microsoft.SharePoint.Webpart unless
required for Windows SharePoint Services-specific Features, as described in this reference
article:
Reference: Best Practices: Common Coding Issues When Using the SharePoint Object
Model
o
Verify that code is thread safe.
o
Verify SQL queries for Enterprise Search, as described in this reference article:
Reference: Best Practices: Writing SQL Syntax Queries for Relevant Results in Enterprise
Search
o
Reference: Checklist for Creating SharePoint Web Parts
Test Environments
Test environments are different from development environments in several ways:
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
51

Neither Visual Studio nor Microsoft SQL Server® database software should be installed.

Test environments should be attached to a copy of one or many content databases.

Virtual machines (VMs) should be limited to 1.5 GB of memory.
The goal in testing the custom applications is to find any failure points (see next section) and test them.
Speed is not important; in fact, for testing purposes memory should be limited, to see what happens. If an
application passes in this type of environment, it probably doesn't have large memory requirements.
Failure Points
The following are failure points—actions that are likely to cause failure at some time in the life of the
solution—and are considered by the Online Services engineering team to be the most common ones:

Altered computer configurations. The developer configures his own computer, and then writes
a solution to mimic those (altered) settings. Then the solution is installed in a clean environment
where the developer has access. The failure point comes when the developer "fixes" an issue on
his own computer, but the problem can't be duplicated in the clean environment.

Solution not named with GUID. The administrator installs the solution using a standard name
rather than a globally unique identifier (GUID). One result of this action is that there is now no
way to version the solution. For example, if the new solution contains a DLL that was installed by
a previous (unrelated) solution, the new instance of the DLL overrides the previous instance.
Another result is that if the Microsoft operations team removes the first solution, the DLL that both
applications are using is removed.

The human element: general. There are numerous ways to deploy solutions, but the best
course of action is to adhere to a process and deploy the same way every single time, eliminating
as far as possible any human variables. For example, needing to assign the same tasks to
different individuals is a failure point. Even the requirement for any documentation at all could be
considered a failure point.

The human element: rushing. Simple changes can be more complicated than they look. For
example, a developer may make a very minor change, such as changing the name of a Web
Part. However, due to time constraints this "minor text change" is not properly understood by the
tester. Consequently, no testing is done, and the install fails. Why? The developer did remember
to change the manifest to point to the new Web Part name, but forgot to change the name in the
Feature receiver. That's just one scenario; a million similar things could occur.

Solution files are fragile. A change in the code or even a change to the structure of the Web site
can keep a solution from deploying properly. There is no developer tool that can show everything
that the solution is going to do. The only thing developers can do is test out each change. It can
be very tough to know whether the latest version of the solution is working or not, especially
because developers rarely wipe their computers clean after each install. It is really the customer
test team's responsibility to verify that the solution works—in an upgrade situation, for a fresh
install, or in the production environment as it is configured today.

Multiple Web front-end (WFE) servers. The environment hosted by Microsoft Online Services
contains multiple WFE servers. It is not uncommon that the code or deployment process will fail
when multiple WFE servers are in a server farm. Make at least one pass against a farm
configuration with two WFE servers.

Incomplete removal of previous solutions. A previous solution may not be completely
removed from development integration or a test environment, causing a number of false positives
to be returned because the wrong version of a solution is still deployed. Clean-up prior to the
installation of a new build is critical to successful development on SharePoint Online. Also, a
detailed list of steps for a complete retraction is necessary in the event of a failed install or failed
smoke test.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
52
Appendix C: Solution Packaging Resources
The following links offer information about SharePoint Online solution packaging:

Creating a Solution
Definition, creation procedure, and code sample of a solution package.

Creating a Solution Package in Windows SharePoint Services 3.0
Overview of the packaging process.

Solutions and Web Part Packages
Solution links in SDK documentation to the Windows SharePoint Services solution framework.

Working with Features
SDK article about working with Features in Windows SharePoint Services.

Understanding Solution Packages in Microsoft Office SharePoint Server 2007/Windows
SharePoint Services 3.0
Bill Baer's blog.

Building and deploying SharePoint Solution packages
Chris O'Brien's blog.

WSPBuilder
A CodePlex tool for automating the creation of Office SharePoint Server solution files.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
53
Appendix D: Customization Package Checklist
Customers can use this checklist to make sure they have proper documentation ready for the Microsoft
Online Services customization package review when delivering custom SharePoint Online Dedicated
solutions. This documentation is required for Microsoft analysis and testing of the customization. If any
component is missing from the customization package, the entire package is rejected.
General Instructions
 Use the SharePoint Online deployment guide template provided by the customer's TAM or
solution architect to indicate the requirements, planned design, and implementation details for the
customization.
 Prior to submission, ensure that all documents (including embedded documents, if any) open
without errors.
 Outline what the customer plans to test and validate (including memory usage, scale, and
functionality). It is important that the customer has validated the third-party product prior to
providing the deployment guide to Microsoft.
Scheduling Information
The scheduling information document must include:
 The expected deployment date for this customization.
 (If applicable) The expected duration of downtimes for deployment configuration and postdeployment configuration of this customization. If no downtime, indicate 0 minutes.
 The estimated date for code-drop submission, based on the customer's development calendar.
Deployment Guide (Installation Instructions)
The deployment guide must include:
 Instructions for installing all the customization package components.
Note: For third-party products, do not point to the vendor's documentation. The customer must
provide Microsoft with the necessary documentation in this deliverable.
 Instructions for conducting the smoke test (validation testing), which confirms that the package
was properly installed and the custom solution works correctly.
 Any architecture diagrams, such as illustrations of dependencies and data flow.
 List of all prerequisite software.
 Notation of the presence of open source code, if any open source code is used in the
customization.
Note: As a part of the deployment guide, the customer is required to provide a waiver in writing
that the customer will be responsible for supporting any issues that arise from the open source
software.
 A list of all design changes, if this design is not the original HLD for this customization.
 Notation of whether the post-deployment validation testing of the configuration must be performed
by Microsoft. If so, provide thorough validation steps for the Microsoft operations teams to
perform post-deployment.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
54
Rollback Plan
The rollback plan must include the following procedures:
 Procedures such as uninstall and clean-up for a situation in which the customization must be
removed.
Note: If it is not possible to roll back a solution, this must be called out in the deployment guide.
Solution Packages
Each solution package must include:
 Final tested code for deployment by Online Services. This needs to have been validated with
CAF.
 CAF report, including explanations of all detected rule exceptions.
 Install and uninstall scripts for the customization package in the Microsoft primary data center.
 Install and uninstall scripts for the customization package in the secondary data center (if
warranted).
Note: Ensure that the .zip file format is used for file compression.
Test Documents and Results
Include details about all elements of the customization that the customer wants deployed, including any
third-party components and other solutions that the customer has purchased. This section must include
the following test documents:
 Test plan that describes what was tested, why it was tested, how it was tested, and whether
multiple WFE servers were tested. This should include details about what assumptions were
made, and a usage profile or any data points that describe the test environment.
 Test scenarios that were tested, and what devices, browsers, latency, or permissions were used
in testing. Describe the variations based on audience and presentation requirements.
 Unit test results that describe what unit tests were run for feature or functionality testing. This
should include which clients were used, what the results were, what dependencies were tested,
and what failure situations were tested.
 Performance and scale test results that describe what performance or scale tests were run
against the customization. This should include which usage profile was used and what
assumptions were made.
Dependencies List
 List of all dependencies for the code, such as a particular Web service, account, database,
solution, feature, patch, tool set, or library.
Event Log
The event log must include the following components:
 Table of all event entries that are generated by the customization, with event IDs. Table headings
typically include error code, severity, and root cause.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
55
 Troubleshooting instructions for all event entries.
Client Troubleshooting Documentation
The troubleshooting information must include these two documents:
 Troubleshooting guidance for client-facing problems.
Note:
For a template that shows the correct format for the client-facing troubleshooting
document, see Appendix G: Troubleshooting Guide Template.
 One or two test accounts for diagnosing problems with related dependencies, if appropriate. The
account should be a low-privilege account that is used for no other purpose.
Source Code
All source code is treated with utmost confidentiality by Microsoft. Details about the treatment of customer
source code can be found in the customer's contract, in the section "Pre-Existing Work."
If the solution is a third party off-the-shelf application, no source code is needed for submission.
The source code section must include the following:
 Project files (where available)
 Source code, validated through the CAF tool
 Public debug symbols for all custom code
Note: Ensure that the .zip file format is used for file compression.
Third-Party Licensing Document
The licensing document must include:
 Any third-party licensing keys or certificates for deployment to the environment.
Note: Be sure to purchase licenses for both the primary and secondary data center computers.
 All details about the testing that has been done against the third-party component or solution.
Customer's Security and Compliance Review Document
We recommend that customers have their own security and compliance team review and approve all
customizations that are being presented to Microsoft Online Services for deployment.
This review document must include:
 The customer's Security and Compliance Review approval of the design.
 All test details from this review process.
Monitoring Document
The monitoring document must include:
 All monitoring guidance and details, which must include all information about logging and
instrumentation for the custom solution.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
56
Update or Revision to an Existing Customization
When updating an existing customization and therefore existing documentation, any change to the
solution requires submission of a complete new package for review that covers the updated solution.
Provide the following components to Microsoft:
 Updated versions of all support documents that are detailed earlier in this checklist, such as an
update for the end-user troubleshooting guide. Include descriptions of anything that has changed
and any new features that could potentially require support or monitoring.
 Summary of changes between current version and previous version, in adequate detail to
describe clearly what has changed. (Use the "Changes in This Release" section of the HLD
template.)
 The original solution source code, for validating against the new source code.
 If appropriate, uninstall (rollback) information for the previous customization, along with a test that
can be run to confirm that the customization has been removed.
 Details about any problems that are expected to be encountered during the upgrade: any errors,
rendering issues, or other problems that might be expected when upgrading the customization.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
57
Appendix E: Building a Mirror Production Environment
There are several ways to build a mirror production environment. This section details how Microsoft
internal development teams approach mirror environments before they deploy customizations to
production. For detailed build documents that are customer-ready for the SharePoint and SQL roles,
contact the customer's TAM. A new build document is produced with each release of SharePoint Online.
Typically, a Microsoft Online Services development machine is configured as an unmodified SharePoint
Online environment using Office SharePoint Server 2007 Standard or Enterprise, and having all
necessary services enabled and running as appropriate to the current development. Everything runs as
an administrator because the developer is either physically on the machine or using Terminal Services.
We recommend testing the code on a lower-permission account (or several accounts, if there is a series
of actions that can be done with different levels of rights in the system).
Test Machines
Having two sets of test machines is optimal. One machine should be configured as an integration
environment where the code is brought in for the first time with a pseudo-copy of the production
environment. This environment is for finding deployment, installation, and functionality issues. It is not
suitable for scale testing or load testing, nor should it be used for user acceptance testing, because
performance is a key concern for that audience. The second environment should more closely mimic the
production environment: it should contain at least two Web front-end (WFE) servers, use SSL certificates
(HTTPS), and have Web URLs that are fully qualified, such as https://portal.contoso.com.
It is not important to mimic the disaster recovery (DR) portion of the environment, nor is it important to
equal the number of WFE servers. However, it is important to consider DR in the deployment guide and
installation/uninstall scripts, because both the primary and secondary data centers must be configured.
Generally assume a linear unit of scale unless network bandwidth, SQL Server throughput, or SQL
Server storage I/O are constraints. The WFE servers above have both the Office SharePoint Server Web
and Query services running on the servers. The index server has only the Index service running, and in
most cases hosts the SSP Web application. The application server hosts Excel Services in Office
SharePoint Server 2007. Finally, expect to have a minimum of two machines running SQL Server,
although for testing only one will be necessary.
Figure 4 illustrates the deployment of production environment hardware without the introduction of heavy
loads or heavy customization.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
58
Figure 4. Sample SharePoint Online topology
Table 9 shows the current hardware configuration for production environment servers.
Table 9. Production Server Specifications
Specification
WFE, Index, and Application
Servers
Machine Running SQL Server
Model
HP DL380 G5
HP DL380 G5
CPU
2x4 Intel Xeon 2.33-GHz Quad Core
2x4 Intel Xeon 2.33-GHz Quad Core
RAM
16 GB
32 GB
Hard Disk
550.4 GB
9894.0 GB
If planning a complete production mirror environment, contact Microsoft Online Services for more details
about hardware configuration. The above machines would be necessary for heavy load and scale testing;
lesser machines or virtual machines (VMs) are generally suitable for all other testing.
For integration environments, Microsoft generally recommends virtual machines, which can be
constrained as follows:

Windows Server 2008, Windows Server 2008 R2, or Windows Server 2003 SP2

SQL Server 2005 - on separate hardware

Office SharePoint Server 2007 SP2 with February 2010 Cumulative Update

32-bit,1.5-GB RAM (32-bit VM fine for integration testing, but a pass on 64-bit hardware should
also be done)
For the production mirror environment, we recommend the following:

Physical 64-bit–compatible hardware; we recommend Intel-based hardware to match production
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
59

Windows Server 2008, Windows Server 2008 R2, or Windows Server 2003 SP2

4 GB of RAM minimum, 8 or 16 GB of RAM if load testing will be done

2 to 4 cores, 2-GHz minimum CPU

2 WFE servers and 1 index/application server

Dedicated SQL Server environment, SQL Server 2005 with latest service pack

Microsoft Forefront® Security for SharePoint Online with SP1
Recommended settings for environments:

Disable automatic updates for Windows Server.

Verify that the page file for virtual memory is on the C: drive only.

Stop and disable the Windows Firewall service.

Add service accounts to the Local Administrators group.

Ensure that NT Authority/Authenticated Users and NT Authority/Interactive are a part of the Local
Users group.

Configure the server to not use the Recycle Bin and configure setup to not move files to the
Recycle Bin.

If desktop antivirus software is installed, configure the antivirus solution to scan files on upload
only.

Copy the Office SharePoint Server 2007 (Standard or Enterprise) installation bits locally.

Install Internet Information Services (IIS) and both ASP.NET 2 and ASP.NET 3.

If the site will contain Asian language sites, go to Control Panel and set the Regional and
Language options (on the Language tab) to install files for East Asian languages.

For IIS, verify that ASP.NET v1.1.4322 and ASP.NET v2.0.50727 are set to allowed status for the
machine's Web Server Extensions.

Uninstall Internet Explorer Enhanced Security through Add/Remove Programs.

Install Office SharePoint Server 2007, and choose Advanced and Complete to install all
components.

When testing indexing, change the default indexing location to a dedicated drive.

After the installation wizard has completed, install the language packs.

Install all QFEs or service packs.

Verify the correct installation and use of appropriate SSL certificates.

Use only fully qualified URLs such as https://portal.contoso.com.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
60
Appendix F: Implementing Master Pages
The Microsoft Online Services Platform Architecture group has prepared the following guidance for
implementing master pages.
Prerequisites

Office SharePoint Server 2007

Office SharePoint Server Publishing Infrastructure
Introduction
Master pages are a feature of ASP.NET 2.0 and share the common functionality in Windows SharePoint
Services 3.0 and Office SharePoint Server 2007. Master pages provide a template that can be applied
across a collection of pages to enable the application of a predesigned style and layout to Windows
SharePoint Services 3.0 site collections and subsites (Web).
In most scenarios, master pages are applied manually after site creation through an Office SharePoint–
compatible editor such as Office SharePoint Designer 2007 or through the Office SharePoint Server 2007
user interface. This requires the Office SharePoint Server Publishing Infrastructure feature; however, in
some scenarios an organization may want to apply a specific master page when a site collection or Web
site is created to complement a governance plan or maintain a consistent visual layout across the
platform.
Sample Master Page Using Clarity Master Page Sample
In Windows SharePoint Services 3.0, when a new site is created it uses the default master page that is
located on the file system. The default master page is referenced as default.master in
%commonprogramfiles%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\GLOBAL.
Windows SharePoint Services 3.0 provides four tokens to reference the master page—two dynamic
tokens: ~masterurl/default.master and ~masterurl\custom.master, and two static tokens:
~site/default.master and ~sitecollection/default.master. (Tokens are specific to Windows SharePoint
Services and are not applicable to ASP.NET 2.0.)
For additional information, see Customizing Master Pages in Windows SharePoint Services in MSDN.
Windows SharePoint Services 3.0 provides classes for responding to Feature events, which allows
trapping and responding to an event that fires when a Feature is installed in the server farm, when a
feature is added to a new virtual server, or when a Feature is removed. Feature provisioning callouts
allow specific code to be written to handle various events that transpire in the life cycle of a Feature.
To develop a server-level Master Page Feature:
1. Create a directory to store all of the necessary resource files required to build the Windows
SharePoint Services 3.0 solution package. In this document, C:\Temp is used.
2. Create a TEMPLATE directory in C:\Temp to store the solution Features and supplemental
resources.
3. Create a FEATURES directory in C:\Temp\TEMPLATE to store the Features used in the solution.
4. Create optional IMAGES and LAYOUTS directories in C:\Temp\TEMPLATE to store resource
files used by the master page.
Note: The directories created in the previous steps are relative to
%commonprogramfiles%\Microsoft Shared\Web Server Extensions\12\BIN.
5. Create a DLL directory in C:\Temp\. This directory will store the Windows assembly (Feature
receiver) used by the Features.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
61
Master Page Feature
Use the following steps to create a Feature that applies the custom master page to site collections when
created either through the Office SharePoint Server user interface or the SharePoint Administration
Toolkit. Features are filing-system–level customizations that contain items that can be installed and
activated in an Office SharePoint Server environment.
To create the site collection Master Page Feature
1. Create a Sample.MasterPage directory in C:\Temp\TEMPLATE\FEATURES.
2. Create Feature.xml in the Sample.MasterPage directory created in the previous step with the
following content which uses the Feature element to register the Feature.
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<FeatureId="<00000000-0000-0000-0000-000000000000>"
Title="Sample Site Collection Master Page"
Description="The sample master page provides an instant style ready to be
applied to your SharePoint site."
Version="1.0.0.0"
Scope="Site"
Hidden="False"
DefaultResourceFile="core"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifestLocation="ProvisionedFiles.xml"/>
</ElementManifests>
</Feature>
Feature.xml defines the Feature properties, to include the GUID, title, description, and other
information to identify the Feature.
The <Feature> element defines the Feature and specifies the location of assemblies, files,
dependencies, and additional properties that support the Feature. In Feature.xml the Title
attribute specifies the name of the Feature as it appears in the Office SharePoint Server user
interface, and is supported by the Description attribute, which can be used to specify additional
descriptive text to identify the Feature. It is best to provide a clear description of the Feature, its
purpose, and its scope in the Description attribute, to easily identify the Feature in the Office
SharePoint Server user interface. The Scope attribute specifies the scope at which the Feature
applies itself. In this example, the scope is at the Site level. The Hidden attribute specifies
whether the Feature is visible in the Office SharePoint Server user interface, and the
DefaultResourceFile specifies the default resource file to be used by the Feature.
The <ElementManifests> element specifies references to element manifests and element files
that contain definitions for the Feature elements.
See Feature Element (Feature) for additional information about the Feature element and
attributes.
3. Replace the GUID in the sample code above with a new GUID using %programfiles%\Microsoft
Visual Studio 8\Common7\Tools\guidgen.exe.
4. Create a MasterPages directory in %commonprogramfiles%\Microsoft Shared\web server
extensions\12\TEMPLATE\FEATURES\Sample.MasterPage. This directory will be used to host
the master page applied to sites by this Feature.
5. Create a ProvisionedFiles.xml in the Sample MasterPage directory with the following content,
which specifies details specific to the master page applied by the Feature.
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<Elementsxmlns="http://schemas.microsoft.com/sharepoint/">
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
62
<ModuleName="OSGMasterPages"Url="_catalogs/masterpage"Path="MasterPages"RootWeb
Only="TRUE">
<FileUrl="Sample.master"Type="GhostableInLibrary">
<PropertyName="ContentType"Value="$Resources:cmscore,contenttype_masterpage_nam
e;" />
<PropertyName="PublishingPreviewImage"Value="/_layouts/images/clarity/clarity.g
if" />
<PropertyName="MasterPageDescription"Value="Sample Master Page" />
</File>
</Module>
</Elements>
ProvisionedFiles.xml defines the resources that are provisioned on the Web server as a component of the
underlying associated Feature.
Feature Stapling
Feature stapling is a method by which developers can apply or attach a Feature to all new instances of
sites using a given site definition and preserving the site definition integrity without the complexity and
overhead of code routines that activate a Feature on a site or collection of sites. Feature stapling is
implemented through a Feature that is specifically designed to apply other Features to one or more site
definitions in addition to making that Feature available to any new sites created from any site definition.
For more information, review the MSDN article Feature Stapling.
To create a feature that uses Feature stapling
1. Create a Sample.Stapler directory in C:\Temp\TEMPLATE\FEATURES.
2. Create an ElementsManifest.xml in the Sample.Stapler directory with the following content, which
specifies the site definitions to which the Feature created in the previous steps applies.
ElementsManifests.xml contains definitions for the Feature elements.
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<Elementsxmlns="http://schemas.microsoft.com/sharepoint/">
<!--Clarity.MasterPage Feature-->
<!--Team Site-->
<FeatureSiteTemplateAssociationId="A89F34C5-66C6-41d4-8CCC362892BBAD42"TemplateName="STS#0" />
<!--Consoto.Web.Master Feature-->
<!--Team Site-->
<FeatureSiteTemplateAssociationId="7E573FEB-418F-4a02-B5432169212B0477"TemplateName="STS#0" />
</Elements>
The <FeatureSiteTemplateAssociation> element specifies the site templates to which the Feature
should be associated. In ElementManifest.xml the Id attribute specifies the GUID for the site
template that the Feature should be associated to, and the TemplateName attribute specifies the
friendly name of the template that is associated with the GUID in the Id attribute. In this example,
the Feature is associated with an example collection of the pre-existing site definitions for both
sites and Webs. Use additional site templates as needed, by adding the identification values in
the <Elements> element.
This uses the Feature element to register the Feature.
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<FeatureId="00000000-0000-0000-0000-000000000000"
Title="Clarity Stapler"
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
63
Description="Clarity Stapler Feature"
Version="1.0.0.0"
Scope="Farm"
Hidden="False"
DefaultResourceFile="core"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifestLocation="ElementManifest.xml"/>
</ElementManifests>
</Feature>
To create the Web-Scoped Master Page Feature, create a Sample.Web.Master directory in
%commonprogramfiles%\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES.
Create Feature.xml in the Sample.Web.Master directory with the following content, which uses
the Feature element to register the Feature.
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<FeatureId="00000000-0000-0000-0000-000000000000"
Title="Sample Web Master Page"
Description="The sample master page provides an instant style ready to be
applied to your SharePoint site."
Version="1.0.0.0"
ReceiverAssembly="SampleReceiver, Version=1.0.0.0,
Culture=neutral,PublicKeyToken=2f0124eb80d993f2"
ReceiverClass="SampleReceiver.FeatureReciever"
Scope="Web"
Hidden="False"
DefaultResourceFile="core"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifestLocation="ProvisionedFiles.xml"/>
</ElementManifests>
<Properties>
<PropertyKey="MasterName"Value="Sample.master"/>
</Properties>
</Feature>
Create a ProvisionedFiles.xml in C:\SampleMasterPage\TEMPLATES.
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<Elementsxmlns="http://schemas.microsoft.com/sharepoint/">
</Elements>
ProvisionedFiles.xml defines the resources that are provisioned on the Web server as a component of the
underlying associated Feature.
Master Page Feature Receiver Sample Code (C#)
The Feature receiver provides the ability to respond to Feature events that permit trapping and
responding to an event that fires when a Feature is installed in the Web farm or is added to a Web
application, or when a Feature is removed. For additional information about Feature events, see
msdn2.microsoft.com/en-us/library/ms469501.aspx.Or, for additional information about using Feature
receivers to modify master page properties and application on an SPWeb object, see blogs.msdn.com
/bgeoffro/archive/tags/branding/default.aspx.
The Feature receiver is the core of the master page solution. It enables a method by which an event is
acted on when the Feature function or functions are called. The Feature receiver used in this example is
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
64
called by the Clarity.Web.Master Feature. Event handlers within the Feature Receiver class are fired
when the Feature is installed, activated, uninstalled, or deactivated. To instruct the SPWeb object to use
the new master page, supply the necessary code inside the FeatureActivated event handler.
In the sample Feature receiver, the master page URL used by the site is set to the custom master page
on FeatureActivated.
Sample Feature Receiver for Server-Level Master Pages
using
using
using
using
using
using
System;
System.Runtime.InteropServices;
System.Web.UI;
System.Xml.Serialization;
Microsoft.SharePoint;
Microsoft.SharePoint.WebControls;
namespace SampleReceiver
{
publicclassFeatureReciever : SPFeatureReceiver
{
publicoverridevoid FeatureActivated(SPFeatureReceiverProperties properties)
{
<try
{
SPWeb curWeb = (SPWeb)properties.Feature.Parent
{
//code
}
string strMaster = string.Empty;
strMaster = properties.Feature.Properties["MasterName"].Value;
if ((strMaster != null) && (strMaster != string.Empty))
{
using (SPSite curSite = curWeb.Site)
{
SPList oMasterList = curSite.GetCatalog(SPListTemplateType.MasterPageCatalog);
SPQuery oQuery = newSPQuery();
oQuery.Query = "<Where><Eq><FieldRef Name=\"FileLeafRef\" />"
+ "<Value Type=\"File\">" + strMaster + "</Value>"
+ "</Eq></Where>";
SPListItemCollection oItems = oMasterList.GetItems(oQuery);
if (oItems.Count > 0)
{
string strSiteURL = string.Empty;
// Get the server-relative URL of the root Web site in the Site Collection.
strSiteURL = curSite.ServerRelativeUrl.ToString();
if (!strSiteURL.Equals("/")) strSiteURL += "/";
strMaster = strSiteURL + oItems[0].Url.ToString();
// Set the URL of the master page used for the Web site to the custom master page.
curWeb.MasterUrl = strMaster;
curWeb.CustomMasterUrl = strMaster;
curWeb.Update();
}
}
}
}
}
catch (Exception ex)
{
throw new Exception("Failed to update the master page.<br>" + ex.Message.ToString());
}
}
// Feature provisioning callouts allow you to write specific code to handle various
events that transpire in the lifecycle of a Feature.
publicoverridevoid FeatureDeactivating(SPFeatureReceiverProperties properties)
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
65
{
//Restore the default values
SPWeb curWeb = (SPWeb)properties.Feature.Parent;
curWeb.MasterUrl = "default.master";
curWeb.CustomMasterUrl = "default.master";
curWeb.Update();
}
publicoverridevoid FeatureInstalled(SPFeatureReceiverProperties properties)
{
}
publicoverridevoid FeatureUninstalling(SPFeatureReceiverProperties properties)
{
}
}
}
Code Licensing
The code presented in this appendix has been released in accordance with the Microsoft Public License
(Ms-PL).
To use the provided sample code, create a new Windows Assembly in Visual Studio 2005 or Visual
Studio 2008, and add a reference to Microsoft.SharePoint.dll.
Note:The Feature receiver is installed in the global assembly cache, which requires the assembly
to be digitally signed.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
66
Appendix G: Troubleshooting Guide Templates
This section presents a sample outline for a Microsoft Troubleshooting Guide (TSG) that is used by the
Microsoft operational support team. The same document can be used by the customer service desk, and
Online Services support team and Online Services operations team. Any event that is raised in the
customer's application must have an associated TSG article, or the event is ignored.
Monitoring Troubleshooting Guide
Use the following TSG for monitoring issues. The customer can copy and paste this into a document.
Monitoring
Troubleshooting Guide
SME: [name]
Customization Version:
Updated: [date]
Document Tracking
Tested By
Reviewers
Group Owner
[Document Title]
This document is a troubleshooting guide for the following issue:
[Issue to be listed here]
Contents
Support Tier Level of Action
Priority
Overview
Instructions
Escalation
Related Documents
Document History
Support Tier Level of Action
[Which support tier should take this action? Help Desk, Second Tier, Server Support,
etc.]
Priority
[Initial priority]
[Possible change in priority]
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
67
Overview
[Background about what applicable scenarios cause this alert to fire]
Instructions
1. What activities should the analyst take?
2. If this TSG is for a monitoring event, be sure to include the following information:
o Event type
o Event source
o Event category
o Event ID
o Error string
o Description of error
o Impact of error
Escalation
[Relevant escalation contacts for TSG]
Related Documentation
[All related documents]
Last Updated By:
Last Saved:
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
68
Support Troubleshooting Guide
Use the following TSG for support issues. The customer may copy and paste this into a document.
Support Troubleshooting
Guide
SME: [name]
Customization Version:
Updated: [date]
Document Tracking
Tested By
Reviewers
Group Owner
[Document Title]
This document is a troubleshooting guide for the following issue:
[Issue to be listed here]
1. Symptoms:
2. Cause:
3. Resolution:
4. More information:
5. Microsoft internal support information:
6. Steps to reproduce:
7. Author ID (e-mail alias):
8. Writer ID(e-mail alias):
9. Tags (keywords):
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
69
Appendix H: Approved Third-Party Solutions
Table 10 shows all third-party solutions that have been evaluated and approved for hosting by Microsoft
SharePoint Online. Customers that purchase these third-party solutions should reference the table to
determine whether the solution can be deployed without an HLD review. Please note the approved
version number; requests for different versions will require a review by SharePoint Online.
If a third party application, or a Microsoft-created application that is not a part of SharePoint Online, is not
included in this list, it has not been pre-approved by SharePoint Online. Thus, it must follow the regular
customization process in order to be deployed to a customer's SharePoint Production environment.
Table 10. Approved Third-Party Solutions
Third Party Tool/Solution
Approved Version
Requires HLD
Review to Deploy
Mindjet MindManager
7
No
AutoCAD utilities (DFW Viewer)
1.0
No
Telerik RadEditor1
5.4.1
Yes
Telerik RadEditor Lite
N/A
No
Telerik RadMenu
4.4.5
No
KWizCom SharePoint Forum Web Part
1.1.00
No
KWizCom SharePoint Survey Plus
2.2
No
Infragistics Ultra Web Navigator (Ultra Web tree)
8.1.20081.1000
No
BrightWork pmPoint
8.0
No
MicroLink Fetch Framework
2.1
No
KwizCom SharePoint Remote List Viewer
2.3.04
No
Kwizcom List Chart
1.1.01
No
KwizCom SharePoint Media Plus
1.1.01
KWizCom SharePoint Picture Library Plus
1.5.01
No
KWizCom SharePoint Image Rotator
1.3.00
No
KWizCom SharePoint Unique Field Feature
1.1.00
No
Metalogix SharePoint Site Migration Manager3
3.6.20
No
Metalogix Extensions Web Service for SharePoint3
4.0.73
Yes
Quest Web Parts
5.1
Yes
Bamboo World Clock
1.0 (HW17)
No
Smiling Goat FeedReader
N/A
No
NewsGator Social Sites2
2.7.277
No
1Telerik
RadEditor does not have its own installation or WSP solution package. This solution is integrated by the
customer into the customer's custom code, and must be reviewed as a part of the HLD customization review process.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
70
2Microsoft
Online Services is working to create an ecosystem of independent software vendor (ISV) solutions that
work with SharePoint Online. NewsGator Social Sites is the first such solution to be pre-approved for use with
SharePoint Online. NewsGator Social Sites is an application that provides enhanced social computing for SharePoint
Online. Fully integrated with the SharePoint environment, NewsGator Social Sites features include social networking,
online communities, enriched user profiles, and enterprise RSS. NewsGator Social Sites helps businesses to better
collaborate, share content, expand employee knowledge, and improve productivity. The pre-approved design is built
on a federated services model, in which the NewsGator Social Sites software is installed on SharePoint Online frontend servers in Microsoft data centers and configured to communicate with NewsGator Enterprise Servers (NGES)
located on the customer's premises or at other providers' sites. This model provides flexibility and agility for
customers who request integration of NGES functionality into their managed SharePoint Online investment. Microsoft
hosts the NewsGator Social Sites software, and will collaborate with the customer to troubleshoot NewsGator-related
issues. The customer is responsible for purchasing NewsGator licenses and configuring the NewsGator Social Sites
software.
3Metalogix SharePoint Site Migration Manager has both a server and client component. Customers are responsible
for the distribution of the client component. SMMM is the second solution to be pre-approved for use with SharePoint
Online. SMMM helps user migrate content between site collections remotely preserving key metadata and data
integrity.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
71
Appendix I: Building Custom Solutions with Web Parts
Web Parts can serve as "building blocks" for custom Web applications and pages. Solutions that include
Web Parts may be written and deployed by either the administrator of a Web site or the individual users
of the Web site to provide easy functional customization.
However, to ensure proper integration and support of custom solutions for SharePoint Online Dedicated,
refer to Table 11. It is not an exhaustive list of best practices for Web Part development and, if a best
practice is not listed, do not assume that it is allowed. Questions regarding use of Web Parts should be
directed to the customer's service manager or solution architect.
The MSDN article Introducing the ASP.NET 2.0 Web Parts Framework provides an overview of
developing safe ASP.NET 2.0 Web Parts. When creating new Web Parts, start by using the Visual Studio
Extension for Windows SharePoint Services 3.0 Web Parts (see Creating a Windows SharePoint
Services 3.0 Web Part Using Visual Studio 2005 Extensions). The template contains references to
necessary dynamic link libraries (DLLs) and helps the customer package the Web Part as an Office
SharePoint Server solution.
Table 11. Best Practices for Using Web Parts
Guideline
Description
Use of Office SharePoint
Server architecture
The SharePoint Online architecture provides several frameworks for functionality,
such as feature deployment. All custom Web Parts should use the Microsoft Office
SharePoint Server architecture to ensure consistent behavior across the application.
Dependence on downlevel legacy .NET
Framework versions
Microsoft Online Services hosted customizations standardize on the .NET Framework
2.0, .NET Framework 3.0, or .NET Framework 3.5 for multiple reasons. .NET
Framework 2.0 provides additional security features, improved memory management,
garbage collection, scalability, and stability. The Online Services environment strongly
discourages dependencies on older versions of .NET Framework. In addition, Online
Services discourages concurrent operation under multiple .NET Framework versions.
64-bit compatibility
All third-party code deployed to the SharePoint Online Dedicated service must be 64bit compatible. This ensures proper use of memory management and scalable
capacity planning in the deployed design.
Modular deployable
Feature solutions
Custom Web Parts (including resource files) must be contained within a SharePoint
Office Server Feature and packaged as an Office SharePoint Server solution in order
to be deployed. The Office SharePoint Server Feature framework enables the
customer to package sets of interrelated customizations as a single Feature, while
also permitting inclusion of multiple Features in a solution package. Solution
packages are the recommended form of deployment for customizations into a
managed SharePoint Online environment, because solution packages can
be deployed, upgraded, and even uninstalled gracefully.
No direct database
access attempts
Customizations should make no attempts to directly access any of the SharePoint
Online databases. Data stores in SharePoint Online should only be updated using the
Office SharePoint Server object model. All database reads or writes should be made
through the services that are provides by the Office SharePoint Server object model,
with no routines attempting direct access to the SQL Server data structures. This
protects the Online Service for upgrades as well as for data integrity.
Referencing SPWeb or
SPSite objects
When referencing the SPWeb or SPSite objects, a "using" statement should be
employed, or alternatively an explicit call of the .Dispose method, to ensure proper
use and disposal of the memory objects.
Reduce unnecessary
round trips
Use caching as appropriate to reduce unnecessary round trips. Improper
management of the number of round trips required for interactions with Web Parts
can be exacerbated by latency conditions. This results in a poor end-user experience,
while potentially affecting back-end service performance. The customer should
expose the cache expiration (duration) as a Web Part property.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
72
Guideline
Description
Minimized attack surface
Input surfaces in Web Parts and other customizations must include boundary checks,
input data integrity checks, and appropriate exception handling to prevent the
potential for cross-site scripting and SQL injection.
Specify Code Access
Security (CAS) policy &
safe controls
When packaging a solution, include a CAS policy for that solution, and if necessary
include the customer's assembly in the safe controls list through the solution.
Requiring Code Access Security and registering safe controls allows Online Services
to maintain a secure environment while allowing customizations.
Error handling & logging
When writing error handling code, inherit from the SPException class to ensure that
the errors are consistent in appearance with any errors from Office SharePoint
Server. Also trap errors at all possible entry points, including constructors. Use
logging where appropriate to help troubleshoot errors. When writing logging code, use
the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs. Also
be sure to use the Page Error event to handle all errors on .aspx and Web Part
pages.
Configuration of Web
Parts
The configuration of the Web Parts being deployed should allow the flexibility of
deploying to the Web application level or lower. This improves supportability and
maintenance. Developers are encouraged to include configuration data with the Web
Part itself as metadata.
Web Part connections
The SharePoint Web Part infrastructure provides a standardized set of connection
interfaces that allow Web Parts to exchange information with each other at run time.
The customer should use these when it is necessary to pass data between Web Parts
and, when appropriate, between a list and a Web Part. There are a number of Office
SharePoint Server filter Web Parts that already emit data. The customer's Web Part
should be able to receive that data if connection with those Web Parts is desired.
User interface (UI) &
presentation layer
When possible, abstract the presentation layer from the logic code by using either
user controls (ASCX) or XSL. If the Web Part requires form input, the customer
should utilize user controls; otherwise, the Web Part should output raw XML and
apply an XSLT to format the output. When using an XSL, store the XSLT as a Web
Part property, allowing for modification from the tool pane. Avoid using a data
tables/dataset approach and HTML formatting in the Web Part.
Delegate controls
Determine whether the functionality or customization to be developed needs to be
done as a Web Part or if it can be done using delegate controls. By using delegate
controls, the customer can easily replace existing controls that are already in the page
using less custom code.
Localization
Avoid hard coding strings and labels; use resources or language files instead. This
allows for easier localization of the Web Part if or when the time comes.
XML mapping
Use the AppSettings object to implement the XML mapping. This can be provided outof-the-box using the existing Settings framework in .NET Framework 2.0. Avoid
creating custom XML files and a strongly typed object for this purpose.
Unsafe updates
Avoid using AllowUnsafeUpdates. Use ValidateFormDigest() and, if necessary,
interact with Office SharePoint Server objects using elevated privileges. In cases
where AllowUnsafeUpdates must be used, set AllowUnsafeUpdates to False in the
try-catch finally block, or a Dispose() method as required by the IDisposable interface
to avoid security holes.
Deployment logging
Installation and deployment logging should be included the event logs to enable
appropriate operational troubleshooting during installation and un-installation.
Querying large lists
When querying large lists, use the RowLimit property in the SPQuery class if all the
results do not need to be returned. Make the limit as small as possible while using
<OrderBy> to ensure the most relevant results.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
73
Guideline
Description
Updating large lists
Use the Web service to update multiple list items if needed. If the customer needs to
update more than one item at a time, avoid using SPListItem.Update() in the code.
When using the Count property of a SPListItemCollection, the property should only be
called once and then stored in a variable where it can be referred to when looping
instead of calling it inside the loop.
Providing source code
and documentation to
Online Services
Source code for third-party Web Parts solutions, whenever possible, should be
provided with good documentation to ensure good support.
Licensing disclosure for
third-party Web Parts
Full disclosure must be provided to Microsoft for licensed Web Parts that are to be
deployed to the Online Services environment. This will be provided as part of the
customization package.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
74
Appendix J: Code Development and Deployment
Responsibilities
Designing and building secure applications is a collaborative effort involving multiple roles. The RACI
chart in Table 12 shows Microsoft and customer responsibilities for deploying custom code in a
SharePoint Online environment. RACI is an acronym for the following:

Responsible (the role responsible for performing the task)

Accountable (the role with overall responsibility for the task)

Consulted (people who provide input to help perform the task)

Informed (people with a vested interest who should be kept informed)
Table 12. RACI Chart for Custom Code Development
Task
Customer/
Partner
Microsoft
Operations
Microsoft
Engineering
Project Management
Initiate and plan project
RA
Gather requirements
RA
Use cases and constraints
RA
Development
Prepare high level design document
RA
I
Review high level design document
C
RA
Build custom solutions
RA
Perform developer and user acceptance testing
RA
Package custom solutions
RA
Write documentation
RA
Run CAF
RA
I
Prepare documentation (deployment, rollback, test, event
log, client troubleshooting, third-party licensing, security
and compliance, monitoring, CAF report , and
dependencies)
RA
I
Review documentation
I
RA
Validate solution
I
RA
Deploy production build
CI
RA
Test post-deployment
RA
I
RA
I
Documentation
Deployment
System Monitoring
Provide monitoring hooks in code
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
I
75
Task
Customer/
Partner
Monitor code with System Center Operations Manager
Microsoft
Operations
Microsoft
Engineering
RA
Patching
Test patching against SharePoint Online environment
I
RA
RA
Deploy to PPE environment
I
RA
Test customizations against patches
RA
I
Deploy patches to production
I
RA
Author fix/change to customization
RA
I
Review and test changes
I
Deploy changes to Production
I
RA
Upgrade PPE environment
I
RA
Validate customizations in a timely manner
RA
I
Author fix/change to customization
RA
CI
Review and test changes
I
RA
Upgrade production environment and deploy changes
I
Break-Fix Remediation
C
RA
Upgrade
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
RA
76
Appendix K: Custom Solutions Using External Databases
When developing solutions, customers may need to have SQL Server database software hosted for their
custom code. Microsoft Online Services supports the use of SQL Server databases following the
guidelines described in Table13. If a database customization item is not listed in the table, do not assume
that it is therefore allowed. Contact the service manager for further information. Online Services supports
only one database for each custom solution that is deployed by a customer.
Notes:
 Databases that are resource-intensive—that have high storage, CPU, connections, and memory
requirements—cannot be hosted. A customer has the option to host a resource-intensive SQL
Server database on its own servers in its own data centers.

Microsoft Online Services is planning to support more than one customer database in the future.
Microsoft will notify customers if and when multiple database support becomes available.
Table 13. SQL Server Support Guidelines
Database
Customization
Supported
Comment
SQL Server database
Yes
The Microsoft Online Services infrastructure uses SQL Server
hosted on the existing SharePoint Online Dedicated infrastructure.
Microsoft supports only one version of SQL Server. The current
version supported by Online Services is SQL Server 2005 SP2 build
9.00.3215.
Custom non-SQL Server
database
No
Microsoft does not support database servers other than SQL Server.
Customers can choose to host such databases on their own
premises and integrate them with Online Services using the
Windows Communication Foundation (WCF) interface with a Web
service.
More than one custom SQL
Server database
No
Online Services hosts a single SQL Server database for customers
on the shared SQL Server infrastructure.
Database data access
No
When developing the code, direct access to the SQL Server
database via technologies such as ADO.NET is permitted only if the
database is hosted by Online Services. All access to the databases
on the customer's premises by custom code must be through a
middle tier developed with a WCF/Web service interface. There can
be no other direct access, such as SQL Server Integration Services
(SSIS), Data Transformation Services (DTS), or Bulk Copy Program
(BCP).
Custom-developed Web
Parts/SharePoint Online
pages with custom database
integration
Yes
Custom applications must be isolated from out-of-the-box features,
and should be running as an independent entity. Failure of the
custom database access should not cause the entire farm to fail. No
standard existing functionality (for example, search and workflows)
should fail due to a failure on a custom database. Ajax UI
implementation is recommended when connecting to a custom
database to minimize page load impact if the custom database
connection becomes slow.
Custom database as an
authentication or credential
store
No
The database cannot be used as an authentication store. No
credentials are allowed to be stored.
Access to SQL Server
No
Customer access to the SQL Server database using the SQL Server
client tools is not permitted under any circumstances, even during
troubleshooting.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
77
Database
Customization
Supported
Comment
Backups of the custom SQL
Server database
Yes
Customers may request a copy of their custom SQL Server
database through their service manager up to once per month.
Depending on the size of the custom database, the logistics of
providing a copy may be challenging. The customer should be
prepared to cover any costs required in transferring a copy of the
database.
Installation of a copy of a
SQL Server database or
scripting the creation of a
custom SQL Server
database
Yes
The creation of the custom SQL Server database within the hosted
Online Services environment can be done by providing Microsoft a
copy of the SQL Server database (not populated) or through the use
of scripting to create the database and associated schema.
Upgrade path
Yes
All databases hosted by Online Services are subject to the same
upgrade strategy as the SQL Server product offering. Customers will
be notified of plans to upgrade the SQL Server build or version in
advance (with six weeks' notice) of the actual exercise and are
responsible for testing that their custom database and the
functionality they are using will work with the new build or version.
As of the writing of this document, Online Services supports only the
SQL Server 2005 SP2 build 9.00.3215.
SQL Server Reporting
Services Web Parts
(Restricted to pre-SP2 SQL
Server 2005 version)
Yes
The SQL Server team has released Web Parts to display data within
a Reporting Services system. However, only pre-SP2 versions of
SQL Server 2000 and SQL Server 2005 Reporting Services Web
Parts can work within a hosted environment. The current design of
the Reporting Services Web Parts requires the Reporting Services
server to be hosted within the same domain as the SharePoint
Online environment. Customers who want to use the shipped
Reporting Services Web Parts should know that Online Services
supports only the pre-SP2 version of SQL Server 2005.
Non-Supported SQL Server Features
Microsoft Online Services supports any standard SQL Server features that are used in development
practices on SQL Server, except the following:

Integration Services (or any SSIS packages, DTS, BCP)

Reporting Services

Analysis Services

Notification Services

Replication
All SQL Server features that are required by the custom design should be detailed in the HLD document
for review and approval by Online Services. Microsoft provides feedback if a feature that the customer
plans to use is not supportable.
Features that are not enabled by default and are not supported are:

SQL Server 2005 data encryption

Linked server configuration

Cross-database chaining

C2 audit tracing
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
78

Common criteria compliance

Server proxy account

Database Mail or SQL Mail

Extended stored procedures (XPs)

Common language runtime (CLR) integration

Ad hoc remote queries (OPENROWSET AND OPENDATASOURCE support)

Native XML Web service (HTTP endpoints)

Custom OLE automation

Service broker or message queuing

Web Assistant (as deprecated in SQL 2005)

xp_cmdshell

Custom SQL Server Agent jobs (maintenance jobs already inclusive of the hosting system)

Trace flags

Lightweight pooling
Terms and Conditions
The terms and conditions for hosting a single database for a custom solution are described in this section.
If a condition is not listed, this does not mean it is automatically allowed. Customers should contact their
service manager for further information.
Database Configuration
Microsoft Online Services enforces restrictions on each database. The database cannot grow above 100
GB. The database is set up with the following configuration:

Full recovery model

Compatibility mode: 90 (SQL Server 2005)

Database ownership set to sa

Database access level for application is set to read/write only

A single MDF file and a single LDF file

MDF and LDF data files are located in dedicated Data and Log locations respectively. For
example, data files (.mdf) should be placed on H:\MSSQL\Data and log files (.ldf) on
O:\MSSQL\DATA.

Data files are initialized at 20 GB for MDF and 5 GB for LDF, with auto-growth set for 200 MB for
both file types; the data files are set for Restricted to a maximum size of 80 GB for MDF and 20
GB for LDF

Remote query timeout set to 600 seconds

Not provided: Full-text search is not enabled, and not allowed when co-hosted on the SharePoint
Online back end

Do not use: SQL Server 2000 backwards compatibility components
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
79
Security Model

Integrated Windows Authentication only

Not allowed: SQL Server standard logons

Not provided: SQL Server manages the sa password, which will not be provided (disabled)
Database Maintenance
All custom databases will have a maintenance window that is similar to that for SharePoint Online
databases:

Weekly full backup (using SQLLitespeed compression)

Daily diff backup (using SQLLitespeed compression)

15-minute transaction log backup, with file retention of 21 days

Weekly index rebuild with a default 80-percent FillFactor

Daily index defrag

Daily update of statistics (with sp_updatestats)

Weekly calls to DBCC CheckDatabase
High Availability Protection

Database is mirrored (high-protection mode) within local data center

Database is log-shipped to remote data center for disaster recovery

Database backup files are copied to tape as follows:
o
Weekly full
o
Daily diff
o
Monthly offsite
o
90-day offsite retention
Connectivity and Access

SQL Server connectivity using TCP/IP protocol only

Access to database via ADO.NET only; no direct access to server or database via SQL Server
Management Studio or OSQL

Database access level for application is set to Read/Write only

Not provided: View server state

Not allowed: the commands create, delete, detach, attach, backup database
Support

Database backup file can be provided via FTP download or courier of a DVD

Custom databases must meet acceptable levels of performance that do not impact SharePoint
operations

Transaction per second < 100

Reads per transaction (one RPC call) < 100,000

Not provided: Archive data to tape for long-term retention
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
80
Note: Microsoft reserves the right to implement indexes to improve performance of the database if
server performance is impacted by the hosted database.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
81
Appendix L: Process to Escalate Customization PostDeployment Issues
Table 14 outlines the events involved in escalating a custom solution issue after the solution has been
deployed.
Table 14: Escalation Process for Custom Solution Issue
Escalation Events
How Communicated
Responsibility
1. Microsoft Online Services successfully
verifies post-deployment steps provided by
the customer in deployment guide.
After completion of the custom solution
deployment, Microsoft e-mails the
customer-designated distribution list of
the successful deployment.
SharePoint Online change
management team
2. Customer identifies issues with deployed
changes.
After internal triage, the customer
submits a service request to Microsoft
Online Services support service desk
(mossup@microsoft.com) by providing
completed escalation template and
severity level.
Customer
The detailed escalation process can be
found in the Customer Run state
Handbook in the Online Services
Customer Knowledge base site.
3. Microsoft Online Services support team
triages the submitted service request and
evaluates the incident based on the severity
level. Refer to the Customer Run State
Handbook for more information about
assigning severity levels to service
requests.
4. If after completion of triage through the
regular service request process Microsoft
Online Services determines that the
customer issue is due to the deployed
customization and/or configuration,
Microsoft Online Services follows rollback
instructions provided in the deployment
guide to uninstall deployed code and/or
configuration. Rollback scheduling is based
on the assigned severity level of the
incident,
Severity A: Rollback is performed
immediately for the customization in
question.
Microsoft Online Services support team
will communicate status of the service
request based on the severity level
assigned.
Microsoft Online Services
support team
Communication to customer via service
request e-mail notifications.
Microsoft Online Services
support team and
SharePoint Online change
management team
Severity B: Rollback of the customization
can be scheduled at an agreed-upon time
with the customer, and can be done outside
a change window with written approval from
customer.
Note: Standard support process, as with
any outage or service degradation incident,
applies if root cause analysis indicates that
issue is due to out-of-the-box functionality.
Microsoft SharePoint Online Dedicated Custom Solution Policies and Process
82