Common mistakes in SharePoint 2013 Arhitecture

I am participating in the upgrade from SharePoint 2007 to  SharePoint 2013 on premises. It is nice to be back in upgrade work since it was my main activity last 6 years). This time it's a little bit different.
First of all, the upgrade is from SharePoint 2007 to SharePoint 2013. We do it through a transitional SharePoint 2010 farm.
And second of all, I wasn't involved in the architecture phase of building the farm. I jumped on the upgrade bandwagon just before the final prod upgrade. So, what I do mainly is  verifying that new farm is in the working conditions and testing once again the content migration.
Along the way I see how people built the farm and streamlined the upgrade process. It's a good experience to have to observe different style of working with SharePoint. I am free of making architectural decisions, but at the same time I am experienced enough to see outcome of decisions that were made by others.
This post is about my observations on common SharePoint 2013 architectural mistakes.

I can get "editing in the browser" feature with no additional configuration
No, you have to have 2 conditions to have Office Web Apps on the farm:
1. Office Web App server
2.  Claim based web application

You need to have OWA server. You can't place OWA on App server. It should be a dedicated server for Office Web App server.Plan for an additional server in the farm.
Office Web Apps can be used only by SharePoint 2013 web applications that use claims-based authentication


OWA server will handle all Excel calculation

Office Web Apps Server enables you to view workbooks that contain Data Models that use native data. However, you can’t explore data in items such as PivotTable reports, PivotChart reports, and timeline controls that use a Data Model as the data source.

(Overview of business intelligence capabilities in Office Web Apps Server and SharePoint Server)

Overview of Excel Services in SharePoint Server 2013

Excel Web App runs in one of two modes:

SharePoint view mode   In this mode, Excel Services is used to view workbooks in the browser.

Office Web Apps Server view mode   In this mode, Excel Web App is used to view workbooks in the browser.

Comparing Excel Online, Excel Services, and Excel Web App

       Excel Services, and Excel Web App all have a lot in common, but they are not exactly the same. These applications can differ in what workbook features are supported for viewing in a browser

More on SharePoint 2013 architectural pain points

SP farm doesn't use SQL alias

 An old and common mistake. I have just recently jumped on the project after the farm was already configured. The first thing that makes me sick in the farm, that there is no alias for SQL.

So, in case you sql server dies and need to make sure that you name the new server the same way as previous one.

SharePoint Online migration: a quick analysis of 3rd party tools for migration

Recently I have finished manual migration to SharePoint Online. 

See SharePoint Online migration: Manual migration. Why, How and what are the problems of manual migration? for details.

And this a quick post is my first glance analysis of leading 3rd party tools for migration:

Note: I am not affiliated to any 3rd party SharePoint migration tools. This analysis done in order to choose (if necessary) tools for my migrations projects.

1. Quest Migration Suite for SharePoint - Quest’s Migration Suite for SharePoint is the complete solution for simplifying SharePoint migrations whether to SharePoint on-premises or SharePoint Online. It virtually eliminates the risks of downtime and data loss. With a single, agentless tool requiring just one install, you can seamlessly move your entire SharePoint environment, as well as Microsoft Exchange Public Folders, and Windows files, to on-premises versions of SharePoint, SharePoint Online, or a hybrid of the two. And if you decide to wait to migrate to SharePoint Online down the road, you’ll already have a tool in place to proceed immediately.

   I used the trial version to trim the content before the actual migration. 

Pro:  I liked the easy installation and easy manipulation with SP objects. I have used extensively In-place tagging. I love that they offer a trial version with full functionality. The only limit is the expiration date. 

Cons: UI is ugly. 

 Price: Unknown.

2. Metagolix Content Matrix .

   I haven't tried it, but I have seen a live demonstration and got a chance to ask questions.

Pro:  The product has a feature of comparison of the objects and manipulation (Incrementation update\migrate capabilities)

It seems that it is more robust than Quest.

I like that they have online version ( for SPOnline farms) of their product for control and governance - ControlPoint.

Cons: I haven't got a price sheet after presentation. The whole deal with hiding price is a big annoyance.

 Price: Unknown.

3. AvePoint Content Manager .

    I haven't tried it, but I have seen a live demonstration and got a change to ask questions.

 Pro: A BIG BIG PRO - THE TRUST. AvePoint VP - Jeremy Thake. He is a well known expert in SharePoint world and has  lots of intelligent and hot topic articles on SharePoint. Because of his involvement in the product I feel a huge inclination to trust these guys.

Prices are not hidden.

Cons: The concept of DocAve 6 Platform is complicated in my opinion. I couldn't figured out which product do I need for migration until I have seen a live presentation.

Price: Content Manager - 995 per SP server (web-front, app server)

"SharePoint 2007 to 2010 Upgrade" online project (part 10) : Upgrade strategy plan

As it's been recommended by Joel Oleson's, we choose a Hybrid upgrade approach

Here is an actual upgrade strategy plan, that I have created before getting my hands dirty with testing and upgrading:

1. SP 2007 Prod analysis

 - Topology.
Topology review showed us that we need to change topology for a new farm to increase performance.
We moved a SSRS server out of the WFEs.

 - Hardware.
Check if you need to upgrade the hardware before the SP2010 upgrade
We had to upgrade all servers in the farm.
We requested a new VMs with appropriate hardware. The old 2007 farm servers will be upgraded
and we will re-use them to make the farm Highly Available.

 - Configuration (external system dependency, ISA configuration)
For an example, after we rolled SP2010 out, we have discovered that current VPN client won't support popup windows in the IE...and SP2010 extensively uses Dialog forms.
Make sure that you thought over all the systems that are using the SharePoint to avoid our mistake. These dependencies should be tested with test SP2010 farm before going live.

 - Customization
To pull all wsp files use the script spExtractSolutionsFromFarm.
Check if you have third-party tools that you have to migrate over.

 - Recommendation
This chapter helps to formulate the scope of the work to present to project manager\customer.


2.  Preparation for SP2010 upgrade


Here are the actual stages that we gone through to make 2010 Upgrade happen:

Stage I: “Pruning”. We need to prepare Prod environment before the actual upgrade. By pruning I mean removing all rudiments that are not used or not proper installed on the current Prod.

Stage II: "Build a new SP2010 farm"

1. Get new machines that meet hardware requirements for SharePoint 2010 


2. Install SP2010 on the new Prod  farm

3. Build topology


4. Configure service applications
Pay close attention to User Profile Synchronization service .
If you have BDC, decide whether you want to convert them into new BDCM models or not.
Depends on your decision, you need \ don't need to run Application Registry Service.


5. Deploy all custom SP2007 wsp files that needed (use the script spExtractSolutionsFromFarm )
Deploy old 2007 wsp file to check what's needed to be fixed to be compatible with SP2010.
For us, it was a big chunk of the functionality that used old BDC API.


Stage III: Test database attach upgrade on the new SP2010 farm
Document all errors that you have experienced during the upgrade, and their resolution. I have used wiki template in SharePoint for easy reference.

Stage IV: Test phase.

1. Build SP2010 farm in the testing region.
I have re-used old VMs, first requesting the up-scale for them

2. Perform the steps from 2-5 on the Test environment

3. Test\Development cycle
Should include iterations for development and re-testing
It took 3 months for us.

Stage V: Run the full cycle of the SP2010 upgrade sequentially for all environments except Prod
Ex: Development, Staging, Training

3: Prod upgrade to SP2010



Helpful to specify assumptions prior the actual upgrade:
 All customizations were delivered on Prod through wsp files.
 All custom solutions are SharePoint 2010 compatible
 Test-SPContentDatabase check  doesn’t show errors




By this time you can do upgrade with closed eyes.
We didn't get any unknown issues. All have been known before since we ran the scenario 5 times already.



1. Set read-only acces on the old Prod

2 . Backup SP2007 content database

3.  Attach SP2007 database to a new SP2010 Farm

4. Run all actions that are needed after upgrade

We had a action upgrade plan, where we put the action that's needed to be taken during the upgrade and after.We put time to perform the operation and a responsible person for it.
It was like a lauching a shuttle, with only one exception - we knew it will launch without failure)


5. Validation


6. Switch ISA to a new farm

7.  Keep SP2007 prod for several weeks to test issues that will be reported by end-user. It will give you a clear answer if the issue is new in SP2010 or it was present before in 2007.


Voila, you did it!

Simple concept: Database is up to date, but some sites are not completely upgraded.

[Question]:
After Mount-SpcontentDatabase, I m having Database is up to date, but some sites are not completely upgraded. on /_admin/DatabaseStatus.aspx. When I click on the /_admin/UpgradeStatus.aspx it shows me the status - Succeeded


How can I know what site collection is not upgraded and how can I upgrade it?


[Answer]:
First of all, to identify what site collection doesn't got upgraded, run:


stsadm.exe -o localupgradestatus > upgradestatus.txt


Open upgradestatus.txt and scroll down to the end of the file, you will see similar section:

In this picture as you see, there no site collection that need upgrade.
If you have any, you can identify them by searching by word "Needs upgrade" in this file.

Secondly, run the command in the PowerShell:


$id=(Get-SPContentDatabase -Identity "{Your content db name}").Id
Upgrade-SPContentDatabase -id $id

Finally, check the upgrade status by running stsadm again:
stsadm.exe -o localupgradestatus > upgradestatus.txt


In my case, it helped me get rid of the site collection "Needs update" warning in the report generated by stsadm.exe -o localupgradestatus


P.S. But still, I am having Status "Database is up to date, but some sites are not completely upgraded." which doesn't bother me since localupgradestatus shows me "0" objects need upgrade.

"SharePoint 2007 to 2010 Upgrade" online project (part 9) : SharePoint service accounts

Here is a bare minimum of the service accounts that I have used for the SharePoint 2010 farm:


SQL Server service account
Setup user account
Application pool account
Service managed account
Default content search access account
SSRS




Automating SharePoint 2010 with Windows PowerShell 2.0 sheds the light on what service accounts are necessary to build a 2010 farm:

"Farm account" - (also reffered to by the SharePoint Configuration Wizard as the Database Connection Account). will be used as the central administration site Application Pool identity as well as the SharePoint Timer Service (SPTimerV4) identity.

Gary Lapointe strongly suggests to user another "Setup SharePoint" account which should be in the Web server local group "Administrators" and should have "dbcreator" and "securityadmin" roles on the SQL server.

You may need to modify the group membership for the farm account in order to start User Profile Synchronization Service


UPDATE: Todd Klindt has an excellent article where he presents his view on what accounts are needed for SP Farm 2010: Service Account Suggestions for SharePoint 2010

"SharePoint 2007 to 2010 Upgrade" online project (part 8) : How to start User Profile Synchronization service

[What you have]:
You have a 2010 farm.

[What you want]:
You want to pull users from AD into Profiles.

[What you want to know]: 
Here is a beautiful represenation of User Profile Architecture from UPA 2010 : Intro – Part1

In order to get AD connection configured, you want to configure User Profile Synchronization.
Before you get your hands dirty with that, the essential understanding of the User Profile architecture is required.

Terminology:

User Profile Application -  a logical set of functionality that allows to have profiles, and if needed social tagging, my site functionality (note: you can configure whether users will be able to create "my site" -Central Administration  Manage Profile Service: User Profile Service -> Manage User Permissions)

"A key thing to understand is that Service Applications, in the general case, are just a logical concept made up of one or more components, one of which may be an actual Service Application component that defines the configurations for a particular implementation of a specific Service Instance." (Gary Lapointe's book)

( you want more of that? - Service Application : Architecture in one picture)

What is the User Profile Synchronization service anyway? - just a wrapper for the ForeFront Identity Manager (FIM) services.

[What you want to do]:

Make sure that:
1. Start the “User Profile Service” first.
2. Create the “User Profile Service Application”
"You must create the User Profile Service Application while logged on as the Farm Account 
This is generally contrary to well-understood best practices that stipulate that you should never log as the Farm Account, but unfortunately, it is a neccessary eveil due to an issue with how the Service Application is created."
(Gary Lapointe's book)

Now you are ready to kick the User Profile Synchronization server off:

1. Make sure that A farm account is in the Farm Administrator group (/_layouts/people.aspx?MembershipGroupId=3).
2. Add temporarily a farm account into Local Administrators group on the application server where you want to run the User Profile Synchronization service.
3. You logged as a farm account into the application server where you want to start the User Profile Synchronization service.
4. Network service account is a member of WSP_WPG group on that application server
5. Don't forget to reset the application server if you have just added a member to the local group. I even would recommend to restart IIS and SharePoint 2010 Timer.

In case NetBIOS Name and FQDN mismatch:

Before Start User Profile Synchronization Service:

First, enable netbios name 

$UserProfileServiceApp = Get-SPServiceApplication | where {$_.TypeName -eq "User Profile Service Application"}                                                                                           

   $UserProfileServiceApp.NetBIOSDomainNamesEnabled = 1                                                                                                                                             

   $UserProfileServiceApp.Update()    

6. Run User Profile Synchronization service on the same application server where the User Profile Service is running.
7. IIS reset after the provisioning of User Profile Synchronization service
8. The permanent assigment "log on locally" must be granted to the Farm Account (Local Policies->User Rights Assignments - Allow Log on locally).
"Though adding the farm Account into the Local Administrator group does achieve this, do not be tempted to leave the Farm Account in the group as doing so is considered a security risk". (Gary Lapointe's book)

9.Check whether User Profile Synchronization works. If it does, remove the farm account from Local Administrator group, you don't need it anymore.

* Because User Profile Sync Service doesn't work with the managed account, if you ever change the farm account password, it will break the user profile synchronization

**Farm backup will stop the User Profile and after the backup job is done, it will try to start the User Profile Service. If at that time all required conditions (That mention above) don't meet, you will end up with broken USP after the farm backup. (Why SharePoint backups break the User Profile Sync Service and other mysteries solved (Todd Klindt))

[What you want to consider]:

To get more details on the topic - Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization

To know exactly what's going on under the hood - refer to UPA 2010 : Setting up the User Profile Service Application

My personal respect to the  author of the post Forefront Identity Manager & User Profile Synchronization Service. This post is responsible for that I got the User Profile Synchronization running.

To encourage me to write you  helpful posts, you can acquire knowledge from a great book by Gary Lapoint through Amazon associate program. (just click this link and buy Automating SharePoint 2010 with Windows PowerShell 2.0)

"SharePoint 2007 to 2010 Upgrade" online project (part 7) : In-place upgrade BDC failed: the bdc service application is not accessible There are no addresses available for this application

[What you have]:
 An Upgraded 2007 farm by means in-place upgrade model ("SharePoint 2007 to 2010 Upgrade" online project (part 3): "Theory"). After you have upgraded the farm, you have [name of your 2007 SharedServices] - Business Data Connectivity Service where all converted BDC files reside.  On click on that service you are getting the error: the bdc service application is not accessible. There are no addresses available for this application

[What you want]:

Fix the error and use the the converted BDC files.

[What you want to know]: 
You may first try to google the error itself. My google findings couldn't  fix the errors. And I ended up removing the broken BDC service. But before removing I exported all converted BDCM files. This post is all about How to export BDCM out of the broken BDCS.

(Btw, still confused with BDC and similar abbreviation? - welcome to read post on SharePoint 2010: BCS and BDC)

[What you want to do]:

Firstly, try to export BDCM using SPD 2010. My attempt has failed. And I happily returned to PowerShell to get my BDCM files out of the Business Connectivity Service 

(Want a quick intro into PowerShell and SharePoint - PowerShell and SharePoint: What, Why and How)

Here is the code to export BDC models:

$models=@(

#array of your model names

);

foreach ($modelName in $models)

{

$path =  "G:\temp\LOCAL\BDCM\{0}.bdcm" -f $modelName;

$Model = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "Model" -name $modelName -ServiceContext {your web application URL}

if ($Model -ne $null)

{

Export-SPBusinessDataCatalogModel -Identity $Model -Path $path -force

Write-Host "The model $modelName has been exported";

}

}

"SharePoint 2007 to 2010 Upgrade" online project (part 6) : Database attach upgrade. BDC to BCS conversion

[What you have]:
 A new 2010 SharePoint farm. Your upgrade strategy is "database attach".

[What you want]:
You want to install your old BDC files on the farm. And probably, you already know that BDC ADF files should be converted first in order to work on the new 2010 farm. So, probably you are looking for the easiest way to convert them.

[What you want to know]: 
 In case of "in-place upgrade" Business Data Catalog adf files will be converted automatically. How Business Connectivity Services upgrade works (in-place upgrade). Make a note that a backward-compatible Application Registry Service doesn't have UI interface to manage it.


In case of "database attach" upgrade strategy, you may have read that you can attach SSP database to migrate its content. Truth is: When you attach an SSP database, only your user profile store is upgraded. Search settings, Excel Service settings, Business Data Catalog (BDC) application definitions, and other settings must be recreated from scratch. Upgrading by using database attach (BDC)


You may have even discovered a lengthy MDSN article (How to: Manually Upgrade Business Data Catalog Application Definitions to Business Data Connectivity Models)that follow you through the whole experience with manually editing ADF file to convert it into a BDC Model.  (BTW, still confused with BDC and BCS? - SharePoint 2010: BCS and BDC (Naming convention))


[What you want to do]:
My suggestion to you - " hybrid BDC upgrade approach".  It's quite simple and probably you have already figured out). 
The idea is to:
1. run "in-place upgrade" on some test 2007 farm with BDC files already installed there;
2. Export BDC Models from the upgraded farm.
3. Import them into a new fresh 2010 farm.



 I see the most common scenario for  "BDC Conversion into Models"  as:
1. "Hybrid BDC upgrade approach"
2. Exporting the upgraded BDC models through SharePoint designer (SPD) 2010.
3. Creating a "Business Data Connectivity Model" project 
4. Deploying a declarative BDC model with  a feature in the new SharePoint 2010 farm.



Regarding details, refer to the material below.

[What you want to consider]:
My fresh experience with BDC upgrade is telling me that you can easily bump into some new errors that you haven't seen before since you have just started using SharePoint 2010.
My recommendation is to follow me. I am planing to get deeper with the BDC conversion and I will share my experience with you.


And some quick notes:


When to Use SharePoint Designer vs. Visual Studio When Building Solutions Using BCS


BDC MetaMan works with .Net connectivity , it won't help with declarative Business Data Catalogs.


The new project template "Business Data Connectivity Model" in Visual Studio 2010  will help you to package and deliver converted BDC. BUT, BDC Model designer in Visual Studio doesn't work with declarative BDC models, only .Net LobSystem,



You can import a model into the Project that was created by using other tools such as SharePoint Designer. You might choose to import an existing model to your project in the following situations:


To customize a model that is already deployed to a SharePoint server farm.


To package and deploy an existing model to multiple SharePoint server farms.

In this scenario this article is a great help - Deploying A Declarative BDC Model with a feature.

Simple concept: After In-place upgrade stsadm.exe crashed

[Question]: why stsadm.exe gives an error after in-place SharePoint 2010 upgrade?
Unhandled Exception: System.MissingMethodException: Method not found: 


[Answer]: You have an old path for stsadm in the environment variables. Change it to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\

"SharePoint 2007 to 2010 Upgrade" online project (part 5) : Backup strategy

[What you have]:
 A SharePoint farm.

[What you want]:
Backup the SharePoint farm in the way that you can restore all of the parts from scratch. Maybe you want to build the exact replica of Prod for staging purposes, or maybe you want to be fully prepared in case of the disaster.

[What you want to know]: 

Here is the backup coverage of the SharePoint data with different tools:

The red  SharePoint blocks are more important than green to back up. The Large blocks are more crucial than smaller.

VM snapshot\server image
As you can see a VM snapshot\server image covers all aspects of the SharePoint farm. You could say - why bother? I will make do with snapshots\images. Before to decide on that be aware of following:
- Image\snapshots restores everything. In some cases, you would like to keep some system state untouched.
- If you want to restore the copy of Prod for staging purposes - You have to take care for  IP\SID that got duplicated in the network after the restore of an Image\Snapshot.To check the SID

Windows backup utility with selected option "System state"
"System State data contains, among  other things, the Windows Registry, the Active Directory service database, the IIS metabase, and system files that are protected by Windows File Protection. You cannot pick and choose which items within the System State you want included. Microsoft actually recommends that you back up all boot and system disk volumes in addition to the server's System State."
(SharePoint 2007 Disaster Recovery Guide)

Central Administration "Backup and restore"
 Central Administration - Operation has a section "Backup and Restore", if you ever have tried to backup through it - you would have  noticed that  the backup has an option to backup "Farm". But even you select this option it will not backup the registry keys, file system, or IIS metabases of your SharePoint servers, and the farm's configuration database.
 This option lack the full coverage, plus it doesn't have a schedule. Every time it's a manual work. My recommendation - use it when needed but don't rely on it as a systematic backup\restore procedure.

SQL backup:
The book Microsoft SharePoint 2010 Administrator's Companion states:
  "If you could back up only one server, it would have to be your SQL server. SQL server contains more than 95 percent of your SharePoint information."
  "With the exception of the SQL server and the operating system, the server hosting the Central Administration Web application  is the most important component in the recovery of a SharePoint installation"

Please refer to How to restore a sharepoint web app from a SQL backup

 I would like to address the issue with  "SQL backup of config database". Partically, the intrigue topic "How to backup\restore SharePoint configuration database"

Microsoft support on Restoration Config db :

 In Microsoft Office SharePoint Server 2007 and in Microsoft Windows SharePoint Services 3.0, restoration of the configuration database is not supported using the built in backup and restore functionality.

The way to perform the full farm backup: Mysterious config database: you can back it up but not restore?

The actual steps to move of SharePoint databases which is similar to copying them: SharePoint 2007 – Move Content and Configuration Databases

My suggestion is: If SharePoint databases are in full recovery mode. Backup all of them, + logs. And restore them at point in time.

Stsadm backup

In SharePoint 2007 out of the box the smallest component you can backup\restore is a site collection.

!I am not aware what functionallity is available regarding backup\restore in stsadm 2010\PowerShell.
Since this post is one of the series "SharePoint 2007 to 2010 Upgrade". My focus is to elaborate the backup plan for my 2007 old farm to make the transition to 2010 safe.

Stsadm backup\restore is a great tool for small easy managed site collections. It doens't work well with large sizes.
To be honest, I don't use it. On Prod we have a big site collection (30 Gb). Even with small site collection stsadm is kind of slow.
 I don't include the stsadm import\export command in this scenario. I consider it is not a backup option, but a way to import and export the site. For more details refer to Sharepoint: How to backup site: stsadm export and SPD backup 

What if you need to restore site collection not the whole web appliaction? Definitely try to utilize stasdm backup\restore

[What you want to do]:
Chose the appropriate backup strategy. Document it. Proceed with backup. Test the restore beforehand.  

Buy the book:  SharePoint 2007 Disaster Recovery Guide

[What you want to consider]:

Should I back the Index server up?

"If your index sizes are measured in gigabytes or terabytes, you will want to back up your indexes so they can be restored, providing a reasonably timed return to service."
(Microsoft SharePoint 2010 Administrator's Companion)
"When requiring a speedy return to service, you should consider using disk-to-disk backups for your indexes."
Microsoft Office SharePoint Server 2007 Best Practices recommends use a native catastrophic backup tool stsadm.exe -o backup -directory to back up and restore SSP. The SQL backup of SSP of search db  doesn't include the search indexes which are stored on the file system on the Search role of the farm.

"SharePoint 2007 to 2010 Upgrade" online project (part 4): "Preparing to install SharePoint 2010. Prerequisites"

The Best Practices are from a book: Microsoft SharePoint 2010 Administrator's Companion *

Best Practice: "People often perform upgrades of existing operating system and software applications. A best practice is to make sure that all components of your SharePoint farm are always fresh installs and not upgrades"

Hardware requirements:

Web\App server:
CPU: 64-bit, 4 core
RAM: 8 Gb
System drive: minimum 80 GB (Why so? - Read on SharePoint 2010 and the C Drive)

Best Practice: "In a production environment, additional free space should equal at least two times that amount of RAM on the server to provide additional space for normal day-to-day operations and for memory dumps"

SQL server:
CPU: 64-bit, 4 core(minimum)
RAM: 8 Gb
System drive: minimum 80 GB

Software requirements

The 64-bit edition Windows Server 2008 SP2

Or

The 64-bit edition Windows Server 2008 R2

The 64-bit edition of Microsoft SQL Server 2008 R2.
Or
The 64-bit edition of Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2
Or
The 64-bit edition of Microsoft SQL Server 2005 with Service Pack 3 (SP3)

For WFE:
You have to have .net Framework 3.5 SP1

For client machines:

 - It's good to know that SharePoint 2010 has a concept of Level 1 and 2 Web browser supportability.
Level 1 ( support all Active X features) - IE; Level 2 - other browsers (support basic functionality)
 - For a richer user experience Silverlight version 3 or higher;

Best Practice: It's strongly recommended that you use a dedicated account to log on and install SharePoint 2010. Don't use your administrator account!

There is a SharePoint 2010 Prerequisite Installer which can automatically install the missing prerequisite software.

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!

* Even though the book is published by Microsoft Press in 2011, it's lacking consistency with MSDN in some places. I have included the quotes from the book that don't contradict MSDN and my opinion. The hardware requirements are from MSDN with a little bit explanation from blogosphere)

"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.