Skip to main content

Posts

Showing posts from April, 2011

Upgrade methods in SharePoint 2010

In SharePoint 2010 there are two upgrade methods available. In-Place Upgrade Database Attach Upgrade Note : There is no Gradual Upgrade method available for upgrading SharePoint 2007 to SharePoint 2010. There is also no direct upgrade method from SPS 2003 to SharePoint 2010. So if you want to upgrade from SPS 2003 to SharePoint 2010 you will have to upgrade SPS 2003 to MOSS 2007 and then from MOSS 2007 to ShaePoint 2010 Let us now have a look at both the available upgrade methods one by one In-Place Upgrade The InPlace upgrade is the easiest way to upgrade from MOSS 2007 to SharePoint 2010. In this approach you will install SharePoint 2010 on the same machine where MOSS 2007 was installed and the Upgrade wizzard will upgrade MOSS 2007 to SharePoint 2010. But make sure that you have run the pre-upgrade check before starting the upgrade to check all the pre-requisites are in place and all the errors are fixed. Here are some of the features of InPlace Upgrade: Very easy.. Wizard driven p

Upgrade to SharePoint 2010

If you have a 32-bit implementation of MOSS 2007, you can’t perform an in-place upgrade to SharePoint 2010. Microsoft recommend 1st upgrading from MOSS 2007 32-bit to MOSS 2007 64-bit and then upgrade to SharePoint 2010. With this best practice, we will be able to identify what assemblies, WebParts, iFilters, 3rd party controls, etc. not supported in 64-bit environment and we can recompile them. Get ready for SharePoint 2010 upgrade: http://go.microsoft.com/fwlink/?LinkId=155576 If your existing SharePoint environment on Windows Server 2003 and in 32-bit, Microsoft recommend upgrading from 32-bit to 64-bit and also from Server 2003 to Server 2008 at the same time and then upgrade from MOSS 2007 to SharePoint 2010 as a separate exercise. With regard to Database server, if you are using SQL Server 2000 in a 32-bit mode, upgrade it to 64-bit SQL Server 2005 SP2 or SQL Server 2008 at the same time and then upgrade it to SharePoint 2010 as a separate exercise. Don’t mix up architecture upgr

Word Automation Services

Have you ever wanted to convert .docx files into PDF? We've heard from many customers trying to perform server side conversions of Open XML files (.docx) into fixed formats (PDF and XPS) using the Word desktop application, and that's what motivated us to create Word Automation Services. As a component of SharePoint 2010, Word Automation Services allows you to perform file operations on the server that previously required automating desktop Word: Converting between document formats (e.g. DOC to DOCX) Converting to fixed formats (e.g. PDF or XPS) Updating fields Importing "alternate format chunks" Etc. If you've done any automation of Word, you're probably familiar with the challenges of doing so – challenges well documented by this Knowledge Base article: http://support.microsoft.com/kb/257757 . With Word Automation Services, those challenges are a thing of the past: Reliability – The service was built from the ground up to work in a server environment, which

State Service Database

The State Service is a shared service that is used by some Microsoft SharePoint Server 2010 components to store temporary data across related HTTP requests in a SQL Server database. In SharePoint Server 2010, the State Service is required by InfoPath Forms Services (including out of the box and custom workflow forms), the SharePoint Server 2010 Chart Web Part, and certain Microsoft Visio 2010 scenarios that do not use Microsoft Silverlight 3. The State service application database stores temporary state information for InfoPath Forms Services, the chart Web Part, and Visio Services. Default database name prefix when installed by using the SharePoint Products Configuration Wizard StateService Location requirements None General size information, and growth factors Medium-large. Size is determined by the use of InfoPath Forms services and Visio Services. Read/write characteristics Varies Recommended scaling method Scale out; add another state database to the service application by using W

SharePoint 2010 DataBase Layers

Microsoft SharePoint Server 2010 introduces both new databases and databases whose distribution and purpose differs over previous versions of Microsoft SharePoint Products and Technologies. This post details the changes in the Microsoft SharePoint Server 2010 database layer. This section provides information about Shared Service Applications that have a database dependency and is not an exhaustive list of all Shared Service Applications available in Microsoft SharePoint Server 2010. At the time of publication this is not 100% complete. Usage and Health Data Collection Service The Usage and Health Data Collection Service collects and logs SharePoint health indicators and usage metrics for analysis and reporting purposes. Logging Database The logging database is the Microsoft SQL Server, MSDE, or WMSDE database that stores health monitoring and usage data temporarily, and can be used for reporting and diagnostics. Search Service Administration Database The Administration Database is wha

Deploying contents between server.

Before considering content deployment concepts and scope, let's consider a basic scenario for which content deployment is a solution. In a typical IT scenario for an Internet-facing site, content is authored by people on your internal network, and some network separation exists. For example, the network may have one or more firewalls between the intranet and the Internet-facing network. In this scenario, internal content providers need access to the SharePoint Server 2010 site so they can author, edit, and approve content, but for security reasons the system needs a way to shield the intranet from incoming Internet traffic. Clearly, Internet users need to access the SharePoint Server 2010 site, which is one reason why IT departments frequently separate servers into two farms: one server farm for internal content and the intranet, and another server farm for the Internet-facing network that hosts a production site. Authors work on the internal farm, while Internet customers view con

Perimeter network scenarios

A perimeter network (also known as a DMZ , demilitarized zone , and screened subnet ) is a small network that is set up separately from an organization's private network and the Internet. The perimeter network allows external users access to the specific servers located in the perimeter network while preventing access to the internal corporate network. An organization may also allow very limited access from computers in the perimeter networks to computers in the internal network. A perimeter network is commonly used for deploying the e-mail and Web servers for the company. The perimeter network can be set up in one of these configurations: Back-to-back perimeter network configuration, with two Microsoft Internet Security and Acceleration (ISA) Server computers on either side of the perimeter network. For more information, see Back-to-back perimeter network configuration . Three-homed ISA Server computer, with the perimeter network and the local network protected by the same ISA Se