"SharePoint 2007 to 2010 Upgrade" online project (part 3): "Theory"

Before to get a "hands-on" experience with an  upgrade, I have decided to delve into the "theory of upgrade SharePoint 2007 to 2010".

  To be completely honest, I actually have participated in the  upgrade of a SharePoint staging farm several times with a successful result. But now, I want to start with a "beginner's mindset". Theory first, the lab exercises later...

   Here are some highlights from the book Microsoft SharePoint 2010 Administrator's Companion for those who wants to know a little bit about the SharePoint Upgrade process:

  To perform an upgrade to SharePoint 2010, you must have SharePoint 2007 with Service Pack2 (SP2) installed.


There are 2 upgrade options: in-place and a database attach upgrade.

In-place - an actual upgrade of an existing environment to SharePoint 2010 (all farm setting stay in place).
A database attach upgrade is a migration upgrade (the server and farm settings are not upgraded. You must manually transfer settings).
The database attach upgrade is considered a safer upgrade option.

You can't facilitate in-place upgrade if:

 - you want to upgrade from a stand-alone installation to a farm installation or vice versa.  To perform such a upgrade, the additional steps are needed. (Refer to Migrate a stand-alone installation to a server farm installation (Office SharePoint Server 2007)

 -  current version is running on 32-bit hardware.(Refer to Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)



  >> do you want to know which upgrade is chosen for "SharePoint 2007 to 2010 Upgrade" online project ? - visit  "SharePoint 2007 to 2010 Upgrade" online project (part 2) : (Hybrid approach)

10 Best Practices for Upgrading to SharePoint 2010:

   1. Before upgrade install SharePoint Server 2007 SP2 (Updates Resource Center for SharePoint Products and Technologies)
   2. Ensure that the existing SharePoint 2007 is functioning properly
   3. Migrate 32x to 64x before the Upgrade
   4. Run the pre-upgrade checker
   5. Perform a trial upgrade on a test farm
   6. Plan for the hardware capacity
   7. Perform a full backup of prod (including hive, config files, IIS)
   8. If you are performing a database attach upgrade, set them read-only
   9.  Avoid adding servers to the new farm during the upgrade
   10. Review logs after the upgrade

It's extremely important that you test the rollback strategy prior to performing an upgrade. Backup all related to SharePoint databases, wsp files, web.config and other web server files that is not included in wsp files.

It's highly recommended to duplicate the prod environment (web server and sql server) and test the roll backup process on there including installation all other web server files. If the recovery process is successful is a good indicator that backup\rollback process is suitable to proceed with the upgrade.

If you have decided to perform an in-place upgrade, make sure that the current servers meet the requirements of SharePoint 2010. Use the pre-upgrade checker for these needs.

In a multiple server farm, it is extremely important to run the prerequisite installer and SharePoint 2010 Setup.exe on ALL servers in the farm before running the SharePoint Products Configuration Wizard on any server in the farm!

For a migration update option refer to Prepare the new SharePoint Server 2010 environment for a database attach upgrade
For an in-place upgrade refer to Perform an in-place upgrade (SharePoint Server 2010)
You may want to consider a hybrid approach proposed by Joel Oleson. Please refer to the post Joel Oleson's Upgrade to SharePoint 2010 Best Practices

In the in-place upgrade as soon as you run Configuration wizard, SharePoint 2007 is no longer available.You cannot pause or roll back this upgrade process.


The biggest post-upgrade task it the configuration of BCS. (Business Connectivity services applications is a replacement for Shared Services Provider)

How many cores in CPU?

Running around with your hardware requirements for SharePoint 2010? And one of them that the server should have 4 cores? Wondering how do you know how many cores your server has?

The easiest way - run the PowerShell
((get-counter "\Processor(*)\% idle time").countersamples | select instancename).length -1

The easy way is to click on Computer-> Properties:

The neat way is to run task manager and look at the Performance tab under the CPU Usage History.

You have as many cores as many windows under the CPU Usage History!
Here is an example with one:

 

Here is an example with two:

"SharePoint 2007 to 2010 Upgrade" online project (part 2): Joel Oleson's Upgrade to SharePoint 2010 Best Practices

I have found a relavant video regarding Best Practices 2010 Upgrade -http://channel9.msdn.com/posts/Joel-Oleson-SharePoint-2010-Upgrade--Migration-Best-Practices-SharepointPTDay-29102010

The super star Joel Oleson's best practices regarding SharePoint 2007 to 2010 upgrade in a nutshell are:

• apply "K.I.S.S" ("Keep it simple stupid!") principle to your "upgrade plan". Come up with  a road map and milestones. Don't roll everything up. Choose essential. Don't turn every service applications on. It's harder to turn them off. And it's actually resource consuming to have all of them running
• Create RACI (responsible, accountable, consulted, informed) chart to figure out the roles of the upgrade team
• Create a user group within a company to collaborate with them regarding an upgrade plan
• Learn what is in Out-of-the-box. "Don't play against SharePoint, but with it"
• Keep your hands off the content database. Don't interact with it. The upgrade will not get through if it notices the content database modification.
• Use testing\staging environment for test upgrade or even applying the service packs. Make sure that you introduce data from Prod to your testing environment. The exact configuration and content databases are highly recommended on the testing environment to run a valid test upgrade scenario.
• Consider a hybrid upgrade approach.

The Hybrid upgrade consists of the  following steps:

1.       create a "new prod" (with hardware capacity for SharePoint 2010) - the exact copy of the prod with exact configuration and content database 2007

2.       test the functionality on the new prod.

3.       set old 2007 farm read-only.

4.       start in-place upgrade on the “new prod”

5.       test the functionality

6.       let the users start using the 2010.

7.       drop the read-only 2007 server

• Do the homework : understand before use it. Read about SharePoint 2010 Upgrade first.

P.S. I hope, I can help you with the last one. Please refer to "SharePoint 2007 to 2010 Upgrade" online project  for a full track of our migration from 2007 to 2010.

"SharePoint 2007 to 2010 Upgrade" online project (part 1) : "The start"

There are 2 types of upgrade: in-place (updating a current configuration database to 2010) and migration upgrade (a database attach update)

The ideal world:

"It is highly recommended that you perform a migration upgrade by installing SharePoint 2010 and then migrating your SharePoint content and configuration settings from your existing version to avoid problems that can be caused during an in-place upgrade or anytime after the in-place upgrade"

         Microsoft SharePoint 2010 Administrator's Companion chapter 22 "Upgrading to SharePoint 2010"

The real world:

      My manager handed me a migration document in which he chose to go ahead with "in-place upgrade" even though he mentioned that "This approach is risky as there is no easy back out plan. All of the break-fix work would have to be accomplished during a single outage window and users would not be able to access the farm during the upgrade process."
        I can just speculate that  the decision was made based on the time, resource and budget constraints. It's worth to notice that the migration plan also includes the migration upgrade for another farm, which should merge with the first one.

      

I have decided to start an online project where I can update online community with real world challenges that I am going to meet during the upgrading SharePoint 2007. The project starts July 1st and is supposed to end in December 2011.

Here is a brief description of the SharePoint 2007 "real world" farm  that we are going  to upgrade to 2010:

1. Infrastructure:

   2 Web servers (load balancing) 64x
   1 Index server 64x
   2 SQL servers 64x

2. Topology:

    1  Shared Service site
    1 Web application with 2 sites collection (the overall size is 15 Gb) with around 40 subsites
    Another web farm with no knowledge at this time regarding size and infrastructure, which should merge into the upgraded 2010 farm.

3.Customization:

    Around 5 sites are created from unique custom site templates. The custom solution are shipped as wsp solution files and includes different types of feature as such: module (aspx files, files with  deployable SPD web parts, application pages), event receivers, timer job, SPD and code-base workflow, custom controls, list template,HTTP handlers.

4. Other:

    There are 10 BDC application that are in use. BDC apps use the Web service connection to BizTalk.
    There 2000 users are created in User Information List. The active users I would say - 100.
    SSRS is in integrated mode with SharePoint. The reports are build based on OLAP, data comes from SharePoint to SQL through  a custom ETL component.

Summary: There are sites that are highly customized which produces upgrade challenges and for sure will create lots of insights to share with you, guys!

SharePoint 2010: Security Best Practices

Security Best Practices for Developers in SharePoint 2010 - some short highlights:

• Before rendering user data on the client, encode it by using the appropriate method from the SPHttpUtility class.  
•  Never Allow Contributor Users to Add Script to the Site (don't include "Add and Customize Pages" permission to their permission level)
• If the custom feature shows or downloads the user downloaded document - add to the header:X-Content-Type-Options: nosniff,X-Download-Options: noopen,Content-Disposition: attachment
• Always specify a charset in the Content-Type HTTP response header.(most common: Content-Type: text/html; charset=UTF-8)
• Validate the Form Digest Canary Before Processing a Postback (var canaryValue = document.getElementById('__REQUESTDIGEST').value;)
• Avoid AllowUnsafeUpdates where possible
• Use SPUtility to Redirect to a Different Page
• Check a SPSite created from user input URL with Microsoft.SharePoint.SPSite.ValidateDomainCompatibility
• Do not allow users to specify arbitrary URLs for SharePoint to connect to. Instead, allow farm administrators to configure a list of URLs that are safe. 

The Moles Framework: SharePoint Unit testing best practices

[What you have]:

You have a SharePoint 2010 application

[What you want]:

You want to automate the testing process for the SharePoint application.

[What you want to know]:

Here is a quick summary of the different types of testings:

Unit Testing - an automated procedure to test a single aspect of the code. It doesn't contain logic branching. The unit test is typically written against public methods and interfaces.

Integration Testing -  verifies the functionality against a target system/platform. For an example, web services, security, stress testing.

Continuous Integration Testing (CI) -   a process that provides a continual verification of code as it is checked into the source repository. To implement such testing  use the Team Foundation Build.

Web Testing - (aka "UI test") -sends HTTP requests and verifies the HTTP response.

Stress Testing -  the purpose of a stress test is to drive the component beyond its normal operating conditions to ensue that it degrades gracefully.

Functional Testing -  any procedure that tests the end-user functionality.

Build Verification Testing (BVTs) - similar to CI but used to determine whether code meets the end-user functionality requirements.


Load and Scale Testing -  The idea is to ensure that the system behaves well under normal high-end load conditions and to understand how an application scales as load increase.

User Acceptance Testing (UAT) -  testing the system from user's perspective. Functional testing by business owners is considered to be a part of UAT.


The most common testings are Unit, CI, UAT.

This post focuses on the Best Practices "SharePoint Unit Testing".

Aim to decouple the code from UI. To make the Unit Testing in SharePoint application possible:

- Use MVP pattern to isolate business logic from the UI and the data source.
- Implement interfaces for your view classes\services.
- Use the Service Locator pattern to decouple a presenter class from specific implementations of the class that the presenter uses.

To remove the uncertainty the dependency classes should be replaced with fake implementations.
These fake implementations are known as fakes, mocks and stub.

Using fake classes is straightforward if you fake the class that is been created by yourself and you have control over how the class is implemented. It can be more challenging if you need to provide substitutes for external classes.

Most  SharePoint objects don't implement interfaces\virtual methods, are sealed with private constructors. This fact makes the "faking" of SharePoint object impossible.

In this case a detouring framework should be engaged.

The Moles Framework provides ability to test SharePoint object via a detouring capabilites.
The Moles is a Visual Studio Power tool - free to download. The moles has 2 kind of classes: Stub and Mole types.
 
Use stubs for your own code and third-party code that exposes virtual methods\interfaces that you are able to override. In other cases, use the mole type. The mole intercepts calls to dependency classes and redirect the calls to a fake object.

 Test a single behavior in one unit test. If you have branching logic in the unit test, that means you should have split the logic into several unit tests.

Use Arrange Act Assert pattern in the unit test.

Prefer  Behaved types over conventional mock and stubs.

[What you want to consider]:   

Take a look at the real-world example of using Unit tests for SharePoint 2010 - Developing Applications for SharePoint 2010 (downloads) 

 A free addition to the book Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices) - bibliography - Chapter 11 will explain in the greater details how to implement unit testing in the SharePoint application

Or, buy the source of this post - Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices)

 

SharePoint 2010: Ajax and Silverlight and others

Here is the highlight from the book Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices)  about using the rich client in SharePoint 2010:


[What you have]:


You have a project that requires to build a rich client on  SharePoint 2010. 

[What you want]:

You want to understand which new RIA (rich internet application) capabilities of SharePoint 2010 suite you the best: Ajax or Silverlight or others? Are there others?
 
[What you want to know]:

Typically, there are three main reasons for developing client-side logic that interacts with a SharePoint enviroment:
  - You want to provide a richer user experience on a SharePoint Web page;
  - You want to perform actions that are unavailable to server-side code running in the sandbox environment, such as accessing information from multiple site collections or retrieving data from an external service.
  - You want to access and manipulate SharePoint data from another application, such as an Office client application or a custom solution.

Decision-making "How to build a rich client" includes 2 main area:

"Data Access".
Options are:
 - client-side object model (CSOM);
 - REST interface,  ASP.Net Web services;
 -  BCS ( as a specific example - using BDC object model). Please refer to SharePoint 2010: BCS and BDC  to understand the relationship between BDC and BCS

"User experience"
 - Ajax;
 - Silverlight;
 - Office client applications;
 -  Stand-alone clients built on WPF, Windows Form applications, a console application or PowerShell extension (PowerShell and SharePoint: What, Why and How )

Here are some considerations regarding what type of rich client is more appropriate:

If RIA app requires substantial computation on the client, prefer Silverlight over Ajax. The untyped nature of javascript will bring the performance down in this case.

Please keep in mind that Ajax in Internet world much wider accepted than Silverlight. If you have decided to build a Silverlight solution, the best practice is to provide  alternative HTML content within the object tag.

Generally speaking, there is a trade-off between reach and capabilities. Pure HTML has universal reach but limited capabilities. Ajax brings richer functionality but  may not be supported by every browser. Finally, Silverlight and Flash provide the broadest set of capabilities but only work if the user installs the plug-in.

Pages that contain Ajax and Silverlight functionality will typically have a higher initial load time than traditional thin client approaches. However, as asynchronous communication model ensures that the page remains more responsive.

Caching strategies, delayed\predictive loading; "minifying" javascript libraries (Microsoft Ajax Minifier)

improve the load time.

To get more sustain knowledge regarding this techniques  refer to RIA Technologies: Benefits, Tradeoffs, and Considerations

 Cross-domain access is possible!

In order for a Silverlight application to access services on a different domain, the external domain must include a client access policy file at the root of the web site (What's New: Silverlight Integration and Cross-Domain Data Access)

Cross-domain access from JavaScript is more complex but is possible under some circumstances (Cross-Origin Resource Sharing)



[What you want to consider]: 

Refer to msdn - Client Application Models in SharePoint 2010


Buy a book to get deeper knowledge of pros and cons of rich client application development on SharePoint 2010: Designing Solutions for Microsoft SharePoint 2010: Making the right architecture and implementation decisions (Patterns & Practices) Part III

 Read a free extra from the book  - refer to Part 3 Chapter 8.

 Take a look at The Client Reference Implementation.