Upgrade Improvements in SharePoint 2010

SharePoint 2010 is great! But great technologies are no longer appealing if people find it difficult to afford them. Luckily, SharePoint 2010 comes with a slew of improvements in supporting upgrade. In this article, we will loop through a list of those improvements to see how they simplify our lives!

Pre-Upgrade Checker

The pre-upgrade checker is a very useful tool to verify current farm’s settings to reduce the risk during an upgrade. As I’ve already mention this tool in another post, I won’t repeat it here to save some space, but you can always check it at this link.

Upgrade Logging

Whenever you perform an upgrade (it doesn’t matter if it is an in-place or database attach upgrade), SharePoint will have two logs created: one will be the actual upgrade procedure log with a naming convention like “Upgrade-TimeOfUpgrade”. The other will be an associated error log to that of the instantiated upgrade in the form of “Upgrade-TimeOfUpgrade-Error.”

SharePoint 2007 provided a poor way to manage log because it forced you to deal with one long upgrade log. Back in those days, such a simple thing as a new log for each time an upgrade starts was almost impossible unless you are willing to delete the old one. Things are much better now, however, with SharePoint 2010, and you would be please to know that you now have an upgrade log for each upgrade, as well as an associated upgrade error log where all errors and warnings are reported (not surprisingly this is the log that you should be going to first if your upgrade is failing for any reason).

Database Test cmdlet

Good news for administrators! SharePoint 2010 now officially supports PowerShell through a snap-in called Microsoft.SharePoint.PowerShell. One usefull cmdlet, namely the Test-SPContentDatabase, can help verify that a Content Database and a web application are in sync by testing the Content Database against that web application for different customizations. Also, it’s an effective way to detect potential issues with data orphans, missing assemblies, missing site definitions, and missing features.

As its name implies, this cmdlet can be run against Content Databases only. It will work with both 2007 and 2010 version, including Microsoft Windows SharePoint Services (WSS) or SharePoint Foundation (SPF). While testing, the Content Database can be attached to the SharePoint 2010 farm, though this is not recommended. Running the cmdlet will incur some overhead and therefore, it should not be used against a Content Database that is currently attached to the farm and is under heavy load.

Visual Upgrade

Switching from the old user interface of SharePoint 2007 to the new look and feel of SharePoint 2010 is more problematic than people might think. In the worst case, applying new style to a heavily customized site may break the layout and render some functions useless. To prevent this, SharePoint 2010 ships with the SharePoint 2007 default master pages and style sheets and a feature called Visual Upgrade. This feature allows site collection administrators and authorized site owners to preview sites with the new SharePoint 2010 look and feel.

With Visual Upgarde, administrators are now empowered with the capability to switch back and forth between the SharePoint 2007 and SharePoint 2010 look and feel. This will become critically important when you are unsure about the result of the action. The two Visual Upgrade options that administrators have during the upgrade are as follows:

• Preserve the user interface — This option leaves the old user interface unchanged. The decision to move to the new SharePoint 2010 look and feel is up to the site collection owners and site owners to make.
• Upgrade to new user interface — You actually have a few options with this option: you can force all sites (customized and un-customized, including all admin pages) to use the SharePoint 2010 look and feel, then site collection owners and site owners will have no control over the upgrade, or you can choose to preserve customized pages.

If you do decide to force an upgrade, be aware that this will reset customized sites back to their site definitions. This means that users will lose all changes they have made to the look and feel of the sites through SharePoint Designer 2007. Depends on the situation, the sites may no longer be functional.

Whatever you choose, you need to inform users about the effects of your decision and train them to cope with that. Well-prepared users will less question on trivial problems, which results in minimized helpdesk support and frustrations.

In case you really want to get rid of the old user interface, make it clear to the users about what they can expect. That should include changes and new features, such as the ribbon, the new page editing interface, and interactive calendars as well as some possible issues. One common problem is with customizations, where pages may not display correctly.

On the other hand, if you prefer the look and feel of existing SharePoint sites, tell site collection owners and site owners that the user interface will be left unchanged during upgrade, and that the choices are now up to them to make.

By default, site owners have control over their sites. The Preview New Visuals option (under Site Settings) allows them to preview the new user interface and then switch between both versions. It will take some time to ensure that everything works correctly. During this period site owners can fix any issues with their pages that appeared after upgrade, and once ready, they can update their sites to the new user interface. However, this control can be override by site collection owners, who can choose to finalize the new user interface. Site collection owners may also want to preserve the previous user interface for their site collection, in that case they have an option to hide visual upgrade settings from site owners.

Finally, site owners should avoid making changes in the new user interface while they are in preview mode, if at all possible, for if they later switch back to the previous user interface, bad things may happen.

References

1. Upgrading to Microsoft SharePoint Server 2010 by Microsoft Office System and Servers Team – Microsoft Corporation (2011)
2. Real World SharePoint 2010 (chapter 2) by Jason Medero – Wrox Press (2011)

Nâng cấp SharePoint 2007 lên SharePoint 2010

View English version

I. Giới thiệu

Nếu bạn là một lập trình viên thường xuyên làm việc với công nghệ Microsoft, đặc biệt là trong lĩnh vực ECM (Enterprise Content Management), bạn hẳn đã nghe nói đến SharePoint, nền tảng phát triển các ứng dụng web ở quy mô doanh nghiệp với độ linh động cao. Ra đời từ các dự án ”Office Server” và “Tahoe” với bản phát hành đầu tiên vào năm 2001, Sharepoint đã nhanh chóng trở thành một xu hướng giữa các công ty lớn. Trong đó phiên bản mới nhất, Sharepoint 2010, mang lại nhiều ưu điểm vượt trội so với người tiền thân của nó, Sharepoint 2007, bao gồm thiết kế giao diện hoàn toàn mới cùng nhiều khả năng mạnh mẽ. Điều này làm nảy sinh nhu cầu nâng cấp các ứng dụng cũ lên Sharepoint 2010 để tận dụng những tính năng mà công nghệ mới đem lại.

II. Các bước chuẩn bị nâng cấp

Mặc dù việc nâng cấp lên Sharepoint 2010 nghe có vẻ rất hấp dẫn. Bạn nên cẩn thận! Bất cứ việc nâng cấp nào cũng luôn đi kèm với rủi ro. Sharepoint 2010 yêu cầu những phần cứng và phần mềm hoàn toàn mới để đổi lấy tốc độ và khả năng mở rộng của nó. Ngoài ra, các môi trường và cấu hình khác nhau cũng là những cạm bẫy có thể làm hỏng quá trình nâng cấp. Dù bạn đang rất thích thú, nhưng nâng cấp cần có một kế hoạch rõ ràng!

Trước tiên, hãy bắt đầu bằng việc trả lời hai câu hỏi: “Có đáng để nâng cấp không?” và “Cần những gì để thực hiện nâng cấp?”. Thông thường, câu hỏi thứ nhất có thể được trả lời bằng cách tìm hiểu những tính năng mới mà Sharepoint 2010 cung cấp. Sau đây là vài tính năng đáng lưu ý nhất (bạn có thể xem danh sách đầy đủ trên website MSDN)

Tính năng	Mô tả
SharePoint Central Administration Web site	Giao diện Ribbon đơn giản hóa việc quản lý ứng dụng web bằng cách cung cấp tất cả các tùy chọn trên một trang. Configuration Wizards cung cấp hướng dẫn cấu hình server farm từng bước một. Central Administration Web site có thể được dùng để quản lý các dịch vụ thay vì sử dụng một trang quản trị rời như trước đây.
Ribbon	Giao diện ribbon mang lại một trải nghiệm người dùng thống nhất. Ribbon có các tab ngữ cảnh để người dùng chỉ thấy các lựa chọn phù hợp với tác vụ đang thực hiện. Đồng thời ribbon cũng cho phép tùy biến.
Business Connectivity Services (BCS)	BCS xây dựng dựa trên Business Data Catalog đã có trong các phiên bản trước đây để cung cấp truy xuất tới các hệ thống bên ngoài. BCS hỗ trợ tương tác với các hệ thống này sử dụng SharePoint lists và Web Parts, và cũng hỗ trợ tương tác với dữ liệu từ Rich Office Clients.
Claims-based authentication	Claims-based authentication là một mô hình chứng thực mới, mạnh mẽ và linh động hơn và có thể làm việc với bất cứ hệ thống định danh nào, bao gồm Active Directory Domain Services (AD DS), LDAP-based directories, các cơ sở dữ liệu chuyên biệt cho ứng dụng, và các mô hình định danh user-centric như LiveID.
Throttling và list controls	Throttling và list controls là hai công cụ kiểm soát tốc độ mới. Throttling cho phép kiểm soát tài nguyên server và được thiết kế để bảo vệ server khỏi bị quá tải vào những giờ cao điểm. SharePoint Server 2010 cũng cung cấp vài thiết lập khác nhằm hạn chế câu truy vấn đối với các danh sách lớn. Những thiết lập này đều có thể được cấu hình cho từng ứng dụng web.
Developer dashboard	Đây là một bổ sung mới hỗ trợ cho việc chẩn đoán các vấn đề của server, đặc biệt là về tốc độ bằng cách cung cấp thông tin chi tiết về mỗi lần nạp trang.
Sandboxed solutions	Với tính năng này, bạn có thể cho phép các nhà quản trị site được tải lên các đoạn code tùy biến mà vẫn hạn chế được nguy cơ về bảo mật và ổn định hệ thống.

Danh sách trên chưa phải là hoàn chỉnh, nhưng nó cũng cho bạn một chút ý niệm về những lợi ích của việc nâng cấp. Nếu sau khi cân nhắc kĩ những lợi ích đó, bạn quyết định rằng việc nâng cấp đáng để thực hiện, thì điều tiếp theo bạn nên làm là xem xét yêu cầu hệ thống. Không như các phiên bản trước đây, Sharepoint 2010 đã hoàn toàn từ bỏ kiến trúc 32-bit. Điều này có nghĩa là bạn sẽ cần cả một máy tính 64-bit và hệ điều hành 64-bit (SharePoint Server 2010 chỉ chạy được trên phiên bản 64-bit của Windows Server 2008 R2 hoặc Windows Server 2008 với Service Pack 2) để tiến hành nâng cấp. Nếu phiên bản SharePoint 2007 của bạn đang chạy trên một môi trường 32-bit, bạn sẽ phải nâng cấp môi trường đó lên 64-bit trước khi bạn có thể nâng cấp sang Sharepoint 2010. Một số điều cần lưu ý khi chuyển sang môi trường 64-bit là:

• Cập nhật Office SharePoint Server 2007 lên cùng một bản service pack trên tất cả máy tính trong cùng farm.
• Khảo sát các ứng dụng 32-bit hiện tại — ví dụ, Web Parts và event receivers, để xem liệu bạn có cần biên dịch lại chúng cho môi trường 64-bit hay không. (Một vài ứng dụng có thể chạy trên cả hai môi trường và không cần biên dịch lại.) Nếu các ứng dụng đang sử dụng là do các bên thứ ba cung cấp, bạn cần liên hệ với nhà cung cấp để kiểm tra tính tương thích hoặc các phiên bản 64-bit của ứng dụng đó.

Cuối cùng, Sharepoint 2010 cũng yêu cầu phiên bản 64-bit của SQL Server 2005 SP3 hoặc SQL Server 2008 SP1. Một khi tất cả các yêu cầu trên đã được thỏa mãn, bạn nên làm thêm một bước nữa để đảm bảo quá trình nâng cấp sẽ diễn ra suôn sẻ: sử dụng công cụ kiểm tra trước nâng cấp (pre-upgrade checker) để phát hiện các vấn đề tiềm ẩn và xem lại các hướng dẫn thực hành tốt nhất (best practices). Công cụ pre-upgrade checker có thể được gọi từ cửa sổ dòng lệnh với cú pháp sau:

STSADM.exe –o preupgradecheck

Công cụ này cung cấp nhiều thông tin giá trị như:

• Một danh sách các máy chủ và các thành phần của farm, và liệu các máy chủ đó có đáp ứng được yêu cầu nâng cấp hay không: bao gồm phần cứng và phiên bản hệ điều hành Windows Server 2008 64-bit.
• Các ánh xạ URL khác đang được sử dụng để truy xuất farm.
• Một danh sách tất cả các site definitions, site templates, features, và các gói ngôn ngữ đang được cài đặt trong farm.
• Các tùy biến không được hỗ trợ trong farm (chẳng hạn như các thay đổi database schema).
• Các cơ sở dữ liệu và site không sử dụng.
• Các thiết lập cấu hình bị thiếu hoặc không hợp lệ trong farm (thiếu tập tin Web.config, host names không hợp lệ, hoặc các tài khoản dịch vụ không hợp lệ).
• Các cơ sở dữ liệu có đáp ứng yêu cầu để nâng cấp hay không — ví dụ, các cơ sở dữ liệu đang ở chế độ read/write, hoặc các cơ sở dữ liệu và site collections lưu trữ trong Windows Internal Database với kích thước lớn hơn 4 GB.

III. Các hướng nâng cấp được hỗ trợ

Bạn có thể nâng cấp từ một máy chủ Sharepoint 2007 độc lập (stand-alone) sang một máy chủ Sharepoint 2010 độc lập, hoặc từ một farm Sharepoint 2007 (có quy mô bất kì) sang một farm Sharepoint 2010. Điều ngược lại (nâng cấp trực tiếp từ một máy chủ độc lập lên farm hoặc từ farm xuống một máy chủ độc lập) không được hỗ trợ. Nếu bạn thực sự muốn nâng cấp từ một máy chủ Sharepoint 2007 độc lập sang một farm Sharepoint 2010, bạn sẽ phải thực hiện theo hai bước: trước tiên, thay đổi cấu hình máy chủ độc lập Sharepoint 2007 thành farm Sharepoint 2007, sau đó nâng cấp farm này lên Sharepoint 2010. Để chuyển từ máy chủ độc lập sang farm, bạn cần phải tạo farm mới, và di chuyển các cơ sở dữ liệu từ máy chủ độc lập sang farm mới này.

IV. Nâng cấp Content Database

Đây là giai đoạn chính của toàn bộ quá trình nâng cấp. Có hai hướng tiếp cận cơ bản: in-place và database attach. Bảng sau tổng kết một số ưu và khuyết điểm của hai hướng tiếp cận này:

Hướng tiếp cận	Mô tả	Ưu	Khuyết
In-place	Bạn có thể cài đặt SharePoint Server 2010 trên cùng phần cứng. Bạn cũng có thể nâng cấp nội dung và thiết lập của farm trong cùng quá trình này.	Các thiết lập của farm được bảo lưu và nâng cấp. Các tùy biến môi trường vẫn còn sau khi nâng cấp, mặc dù có thể cần thêm một vài bước thủ công để nâng cấp hoặc khôi phục chúng.	Servers và farms phải tạm ngưng phục vụ trong lúc nâng cấp. Quá trình nâng cấp diễn ra liên tục. Do đó, bạn cần sắp xếp đủ thời gian để nâng cấp tất cả nội dung.
Database attach	Các cơ sở dữ liệu nội dung được nâng cấp độc lập với farm. Kết quả là bạn sẽ không còn các thiết lập và dịch vụ. Bạn có thể nâng cấp các cơ sở dữ liệu theo bất cứ trình tự nào và thậm chí nâng cấp nhiều cơ sở dữ liệu cùng lúc. Khi mỗi cơ sở dữ liệu được nâng cấp, người dùng sẽ không thể truy xuất nội dung của cơ sở dữ liệu đó.	Bạn có thể nâng cấp nhiều cơ sở dữ liệu nội dung tại cùng một thời điểm, giúp cho tốc độ nâng cấp có phần nhanh hơn so với hướng tiếp cận in-place. Hướng tiếp cận này cũng cho phép bạn gộp nhiều farm lại thành một farm duy nhất.	Các thiết lập tại server và farm không được bảo lưu sau khi nâng cấp. Bạn phải chuyển thủ công các thiết lập cần thiết sang môi trường mới. Các tùy biến cũng cần được chuyển sang thủ công và nếu chuyển thiếu có thể gây nên những mất mát không mong muốn về chức năng cũng như những vấn đề về trải nghiệm người dùng. Sao chép cơ sở dữ liệu qua mạng tốn thời gian và băng thông. Ngoài ra, bạn cần phải truy xuất trực tiếp đến các máy chủ cơ sở dữ liệu.

V. Kết luận

Trên đây là các bước chính của quá trình nâng cấp. Trong khuôn khổ giới hạn, bài viết mong muốn trình bày cho bạn một cái nhìn khái quát về toàn bộ quá trình nâng cấp hơn là đào sâu về mặt chi tiết. Hi vọng là với những kiến thức căn bản có được, bạn có thể tiếp tục nghiên cứu để khám phá những tình huống cụ thể hơn. Chúc bạn luôn cảm thấy thích thú khi làm việc với SharePoint 2010!

VI. Tham khảo

• What’s new in upgrade (SharePoint Server 2010)
• Determine upgrade approach (SharePoint Server 2010)
• Review supported and unsupported upgrade paths (SharePoint Server 2010)
• Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)