SharePoint world of ECM and Information Management : Migration

SharePoint 2007 Farm ports – configuring firewall

Michael — Wed, 04 Nov 2009 11:42:00 GMT

Introduction

Depending on the environment you are configuring you might need not only open ports between client and your Web Front End(WFE) servers, but you might have internal topology where your SharePoint servers are separated by layers and are isolated by firewalls. In such situation you need to know the inner-process communication ports and direction, to open the ports on firewall.

The following table describes all ports SharePoint 2007 uses for the communications. Take into account that only 2 posts are used between client PC and WFE (the indenting line). All other ports are for internal and external communications between SharePoint servers.

The advantage of this document is that I summarized all ports together that are described in different documents, and included directions. Microsoft doesn’t provide you the summary info for ports and directions.

SharePoint 2007 Ports

Inbound/Outbound	From	Port	Type	To
Inbound	Client IPs (as applicable)	TCP 80 or 443 (SSL)	HTTP	ISA Web Pub or WFE
Inbound	TS Jump point	RDP (TCP 3389) For Remote Admin		APP (Central Admin /SSP Admin)
Inbound	All SharePoint Server (Depends on Central Admin configuration)	Office Server Web Services, TCP 56737, SSL 56738	HTTP	App - Central Admin /SSP Admin (Web Service Control)
Inbound	Index	TCP 80 or 443		WFE
Outbound	ALL SharePoint Servers (Based on Authentication)	DS (TCP 445) RPC (TCP 135) DNS (TCP/UDP 53) Kerberos (UDP 88) LDAP/S (UDP 389/636)		DC (AD) /DNS (LDAP)
Outbound	External Content	DNS (TCP/UDP 53)		DNS
Outbound/(Inbound if applicable)	WFE (alerts or mail enabled list)	SMTP (TCP 25)		SMTP/Exchange
Outbound	ALL SharePoint Servers	SQL (TCP 1433) or custom port for Named SQL Instance	SQL Server Tabular Data Stream (TDS)	SQL Server
Outbound	WFE (Search Request)	Search Query, either NBT (TCP/UDP 137, 138,139) or Direct-hosted SMB (TCP/UDP 445)	Server Message Block (SMB)	Query
Outbound	Index (Propagation)	Search Query, either NBT (TCP/UDP 137, 138,139) or Direct-hosted SMB (TCP/UDP 445)		Query
Outbound	Index (File Shares)	Either NBT (TCP/UDP 137, 138,139) or Direct-hosted SMB (TCP/UDP 445)	Server Message Block (SMB)	External Content
Outbound	Index (BDC)	SQL (TCP 1433) or custom port		External Content
Outbound	WFE (SSO)	RPC for SSO – (TCP 135), plus random high ports (Dynamic RPC) or restricted high ports (Static RPC)		APP Servers
Outbound	WFE	TPC 80, TCP 443, TCP (custom)	HTTP	Index Server (search crawling)
Outbound	Index (Search Crawling)	TPC 80, TCP 443, TCP (custom)	HTTP	WDE
Outbound	Index (Sites)	TPC 80, TCP 443, TCP (custom)		External Content

Inter-server communications of SharePoint 2007

Extra -server communications of SharePoint 2007

Firewalls

Depending on you farm design you might require firewall between your farm’s servers. In case of separate networks you should know that one-way trust relationship is required between WFE and Applications Servers, Application Servers and Database, if they are separated by network.

You need to configure firewall properly for domains and trusts http://support.microsoft.com/kb/179442/

Sources:

http://go.microsoft.com/fwlink/?LinkId=85533&clcid=0x409 (Visio diagram with ports for the inner-server communications)
http://blogs.msdn.com/uksharepoint/archive/2009/01/05/sharepoint-ports-proxies-and-protocols-an-overview-of-farm-communications.aspx
http://blogs.msdn.com/joelo/archive/2007/02/13/protocols-ports-and-firewall-rules.aspx
http://technet.microsoft.com/en-us/library/cc287966.aspx
http://technet.microsoft.com/en-us/office/sharepointserver/cc979168.aspx

SharePoint 2007 to SharePoint 2010 Farm Migration. Phase 2 – Security Analysis

Michael — Tue, 03 Nov 2009 07:56:00 GMT

Introduction

In the current series I’d like to describe how to analyse the SharePoint Farm and prepare it for the SharePoint 2010 migration. We will review the following 3 sections:

Farm Architecture and Configuration Analysis
User and Group Analysis (current)
Farm Migration

This section describes the user analysis and permission analysis. But first of all – why do we need to analyze users and permissions when we only migrating data?! Can’t our users be migrated automatically?!

The answer is yes and no - users will be migrated automatically, but migration is hardly planning for the sake of migration and usually you are building a new application and trying to fix existing issues. Users, Groups and Permissions are needed to be reorganized and to be fixed before moving content to new environment.

The areas we need to look at are the following:

number of users and group
how users are organized in groups
permissions – users, groups, broken inheritance
dead users

SharePoint OOTB functionality doesn’t cover all our needs, so we are going to use several 3rd partly tools to gather the necessary information.

Tools

[free] SharePoint Administration Toolkit (you need to install and to activate “Permission Report” feature manually)
[free] SharePoint Access Checker
[free] Bamboo SharePoint Analyzer
[free] Xavor SharePoint Admin Tool
[free] SharePoint Work Accelerator Toolkit 2007
(optional) [commercial] ARK for SharePoint 2007

Additionally, you need to use the following STSADM commands

enumuser/enumgroups/enumroles
unlockfgpreport (http://technet.microsoft.com/en-us/library/ee449564.aspx) to unlock how much list items can be enumerated for the Permission Report

There are two approaches to collect required information – using commercial “ARK for SharePoint 2007” reporting tool that covers almost all our needs or using several free tools to get the same information. We can achieve almost the same via “enumuser/enumgroups/enumroles” command of STSADM, but we need to count the items manually.

The limitation of the majority of free tools is that they don’t provide web-application level information across all site collections. The advantage of “ARK for SharePoint” is that it generates reports for all web applications in our farm.

In this post I’d like to describe the steps of how to get all information without using commercial tools.

Number of Users & Groups

Users & Groups number – “Bamboo SharePoint Analyser" –> Farm->Servers->Web Applications->Site Collections –> Web sites and the values are in parentheses for “Users”, “Groups” and “Administrators”
Site Administrators – use “Bamboo SharePoint Analyzer” of Central Administration
Groups across site collections - use “Xavor SharePoint Admin tool” –> Show Group Security

Users & Groups Association

Farm Administrators – Use Central Administration –>Operations-> Update Farm Administrators Group or “Bamboo SharePoint Analyzer”
Users by Group – ARK for SharePoint provides full info across all web applications. Alternative free solution is to use “Permission Report” tool functionality (Site Settings -> “Broken Inheritance Reports Jobs”) that generates Excel spreadsheet for the Site with the user’s and its groups.

Permissions

Broken inheritance can be found via “Access Checked” tool that shows SharePoint items where permission is broken, but tool doesn’t show what exactly is broken and list of changes. Reports are supported.
Broken inheritance Diff can be viewed with “SharePoint Administration Toolkit” and its “Compare Permissions Sets” report that shows the permissions difference between the current and root items, and also the details about permission changes . Reports are supported.
User rights – “Check User Access” report of “Access Checker” show the rights for the users across SharePoint elements, including the items where user don’t have access
Group rights - “Check Effective Permissions” of “SharePoint Administration Toolkit” shows the items accessible by this group

Unfortunately, all previous tools don’t provide web-applications scope reports and item-level reports. It means that you can’t iterate through all site collections and find the List items or specific pages where user has no access. To get such information use “Xavor SharePoint Admit Tool” that provides reports across web application (but no functionality to save them)

(red – user has no permissions)

Dead Users

When you install and configure the new farm you probably create several test users and groups that should be deleted in the end. Sometimes administrators create such users and then forget to delete them. So, “dead” accounts is a quite common scenario. When you start a new migration you don’t want such users/groups in your new farm and you need to find all of them and delete.

I don’t know any free tools that provide such functionality. And there are only a couple of the commercial tools that allow to do this: DeliverPoint and ControlPoint

Creating the report

The logical outcome of the Security Analysis is the Word document that highlights the security issues, but unfortunately this is not always feasible. Consider the medium farm with 5000 users 300 groups and 400 sites with 30% of broken inheritance. You can physically create the word document but how are you going to analyse the 200 pages document?!

The real Analysis is usually a “multithreaded” task, when you check users’ rights, discuss the grouping with DC admins, fix the broken permissions and etc.

Depending on the content size documenting the following quantative information is recommended:

Farm Administrators
Number of users
Number of groups across web application and per site collection
Broken inheritance report per site collections and items (depends how much broken items you have)
Users/AD per Groups (definitely for AD, but depends on number of users)

Unfortunately, it’s hard to define the template for this step, because security analysis is very individual for the farm, and usually you end up with several files – documents describing quantative info, excel spreadsheets with users, groups and permissions, html files describing the broken permission inheritance.

Resume

Security analysis might be a daunting task depending on the level of your permissions customization and user’s assignment to groups. The recommendation is to perform the draft analysis on backup instance where you can experiment with different tools and find all security breaches, and after that fix issues on production.

SharePoint 2007 to SharePoint 2010 Farm Migration. Phase 1 – Configuration Analysis

Michael — Sun, 01 Nov 2009 11:06:00 GMT

Introduction

In the current series I’d like to describe how to analyse the SharePoint Farm and prepare it for the SharePoint 2010 migration. We will review the following 3 sections:

Farm Architecture and Configuration Analysis (current)
User and Group Analysis
Farm Migration

The first and the most important step in SharePoint 2007 –>SharePoint 2010 migration is the understanding of existing SharePoint environment to get enough information to design the new Farm.

Let’s review in details the following template that I’m using to document the farm settings and tools that allow to gather all necessary information (we don't describe search, excel and other services settings here)

Farm Information
1. Farm Servers and Services
2. Web Applications
3. Content Database and Site Collections
4. Alternative Access Mapping
5. Farm Solutions
6. Enabled Farm Features
7. Search Settings
Site Information
1. Web Parts
2. Web.config changes
3. Site Definitions
4. Customized & Checked-out Items
Sites Topology
1. Sites
2. Sites Structure Diagram
3. Site Collections with Diagrams
Issues

1. Farm Information

Content: This section enlists farm servers, components from the farm and general information about farm configuration (email settings)
Tools: STSADM –o “preupgradecheck” (Upgrade Planning Information section for servers and components) & Central Administration to get the mail settings

a) Farm Servers and Services

Content: table with the farm servers and assigned roles
Tool: Use the Central Administration & SharePoint Manager 2007 to get this information

b) Web Applications

Content: List of web applications and its URS
Tool: Central Administration

c) Content Database and Site Collections

Content: Table with the following info – content database name, number of sites, size, list of site collections
Tool: SharePoint Diagnostic tool for the Content DB size; Central Administration and SharePoint Administration Toolkit (Batch Site Manager Solution)

d) Alternative Access Mapping
Content: Table with AAM Internal/External URLs and Zones
Tool: “preupgradecheck” log & SharePoint Diagnostic

e) Farm Solutions

Content: Table with the installed solutions and sites where they are active
Tool: SharePoint Manager 2007 / Bamboo SharePoint Analyser

1.f) Enabled Farm Features
Content: List of enabled features on the farm level
Tool: Central Administration
1.f) Search settings
Content: SSP settings (servers, databases name, crawling settings)
Tool: Central Administration & SharePoint Diagnostic

2. Site Information

a) Web Parts

Content: list of installed web parts
Tool: Bamboo SharePoint Analyzer

b) Web.config changes

Content: list what was changed in web.config for SharePoint sites
Tool: SharePoint Diagnostic shows web.config for each web application, but developer/admins own the knowledge about the changes

c) Customized & Checked-out Items

Content: list of customized & checked-out items
Tool: SharePoint Designer, choose Sites menu –> Reports –> Shared Content –> Customized Pages / Checked-out items

3. Sites Topology

a) Sites

Content: list of sites
Tool: Site Settings of the root site –> “Site hierarchy” item

a) Site Structure Diagram

Content: diagram of the root site
Tool: SWAT tool –> right mouse click on the site name and Show Site Diagram

4. Sites Topology

Use “preupgradecheck” log to document all found issues
use SharePoint Designer Diagnostic tab, to discover the potential issues

Tools

To get the necessary information I recommend to use the following tools:

Bamboo SharePoint Analyser
SharePoint Manager 2007
STSADM –o “preupgradecheck”
SWAT
SharePoint Administration Toolkit - SharePoint Diagnostic tool & “Batch Site Manager Solution” feature
SharePoint Designer

Resources: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=245

SharePoint 2007 32bit->64bit migration Strategy

Michael — Wed, 07 Oct 2009 02:30:00 GMT

As you know, Microsoft will release SharePoint 2010 public version soon, and there is no space for 32bit versions anymore. All server stuff come in 64bits only – Windows Server 2008 R2, SharePoint 2010 and etc, so, we need to be ready for this.

I recommend to watch New Zealand TechEd session “Upgrade Planning and Guidance OFC306” that describes how to plan you 32bit –> 63 bit migration for SharePoint Farm

SharePoint 2007 migration tips

Michael — Wed, 17 Sep 2008 22:11:00 GMT

Working of migration of SPS to MOSS 2007 in these days and would like to share my experience about number of small tricks, which really annoys you if you don’t know them, and which could save hours during your next migration

Check that SharePoint 2003 doesn’t have Orphans. There are several ways for this
Remove EXE, MSI, DLL extension from blocked types, because these files could exist in your collection and your can’t export such sites. (I usually remove everything from there)
Check source web.config to migrate all 3^rd party Web Parts into new environment (use –haltonwarning in stsadm –o export to find the pages with missed Web Parts and then navigate to source pages to export DWP from there)
Export with –incluseuseonwers attribute
Change the maximum upload file size: Central admin ->Application management ->Web Application General Settings. Set 250mb for example, or the size of the biggest file
Set yourself as secondary admin(stsadm –o siteowner –url <site> –secondarylogin <user_name>), because export wont work against content if you are not admin on target site collections
Before making export make sure that you are site owner for the sites you are going to export (stsadm –o siteowner –url <site> –secondarylogin <current_account>). Otherwise you can’t create any sub-sites during importing and will get strange errors.
Use STSADM –o export with cabsize 1024, otherwise you silently miss some files in your export package if your site size more that 25Mb (default value)

Update: be very careful with renaming database, because if you will do it wrong way you DB is completely screwed, and there is no way to return it back. Refer to this document http://blogs.technet.com/corybu/archive/2007/06/01/detaching-databases-in-moss-2007-environments.aspx about the right process how to rename database

Update 2: Make sure that you have latest SP installed for your SharePoint 2003

Update 3: Check your publishing pages (if you have any) by trying to edit them. Sometimes they can be broken after migration. You need to use these approaches – one and two to fix it.

You are welcome to share your migration tricks which saved your time

Mirror: SharePoint 2007 migration tips

Renaming server PC with Sharepoint

Michael — Thu, 24 Apr 2008 18:36:00 GMT

Usually all Sharepoint development happens on virtual environment. There are several advantages of this, like

creating snapshots of your system to mitigate system restore when you broke your environment
creating Sharepoint farm on the single PC, when you can easily run different virtual systems and setup sharepoint farm there

But when you are cloning your existed sharepoint system you end up with absolutely the same sever, including the same server name name. And this is the only problem. However, renaming server name with the installed Sharepoint is not trivial as you could expect.

There are several items which should be renamed - server name, database name, Sharepoint references. And the situation became complex when your Sharepoint sites use Sharepoint Search - in this case you need rename MSSQL$MICROSOFT##SSEE database.

Actually, I failed with renaming Sharepoint Search DB, and decided to turn search off before system renaming.

The follow steps should be done to rename server with installed Sharepoint

Go to the Sharepoint Central Administration > Operations > Services on Server and stop "Windows SharePoint Services Search"
To go the Control Panel -> System and rename your server (save your old name somewhere). Don't restart your system
If you have MS SQL Server installed on the same box you need to rename in too - go to "SQL Server Management Studio" and execute the following script

EXEC sp_dropserver '<old_name>' GO EXEC sp_addserver '<new_name>', 'local' GO
Update Sharepoint references to the PC name calling the next command: stsadm -o renameserver -oldservername <old server name> -newservername <new server name>
Restart your PC
If you try to open Central Administration after restarting PC it will try to open the site with the old server name. You need to recreate your Central Administration site for the new server name calling the following command(any port address): psconfig -cmd adminvs -provision -port 1800 -windowsauthprovider "onlyusentlm"
Now if you restart IIS and try to open your Central Admin site it will successfully open your site with new server name
Go to the "Application Management" and remove Central Administration Web Site with old server name

That's all. Now you have the clone of your virtual server with the new server name.

Update: Guideline how to rename content database: http://blogs.technet.com/wbaer/archive/2008/06/16/renaming-content-databases.aspx

Mirror: Renaming server PC with Sharepoint