Pages

Friday, March 25, 2011

Moving Large MOSS 2007 Sites and Content

 

[Note : This post is part of  my main blog on “SharePoint 2010 Migration”]

What is Moving Large Sites?

  • If your Site Collection is over 200GB and hence the underplaying dedicated content database should be over 200GB exceeding the Microsoft recommended Max size for Content Database.
  • The Content and Site segregation effort is to move out such data to separate Site Collections and in to a separate content database or an existing smaller database if you prefer, there by reducing the over all size of your larger content database.
  • The your site collection could have several Lists and Libraries with over 1000 items and over 2000 items per list or library and they might be continuing to grow.
  • The site collection may also has several Document libraries that are over several GB in sizes and may or may not fall under the above said categories of over 100o items.
  • You will need to analyze to understand where things are growing.  I will cover the steps for this in the Analysis section below.
  • Hence your design for moving such content requires a very flexible approach to pick and choose each given list, library and may be an entire site (SPWeb) to be moved to given new site collection or an existing site collection.
  • I call this moving selective content to separate sites as “Segregation”.

Design Considerations

  • You want to ensure that the segregated content in the new site collection carries all content, date and time stamps, metadata, pages and applicable settings, security information.
  • You want to your segregation approach to be able to handle each given scenario such as move a site, move a list or library.

Available tools and options

MOSS 2007 has following two options when it comes to moving/copying content:

  • Content Migration APIs (PRIME): More granular support (Up to item level), full fidelity.
  • STSADM export/import operations: Uses the above API but less granular (Web Level Only), less fidelity.
  • Content Deployment UI interface via the Central Admin interface, does not apply here as it is meant for deploying to a target site.

Design Approach

  • Based on the need to support the individual items consider implementing a data file so that you can feed the data file to your process.
  • The configuration data file should mention a give list , library or a site as Source Object to be moved.
  • For each such Source Object, a Target should be mentioned.

    • The target can be a  new or an existing site collection,

    • For existing site collection, the location within the site collection as where to be moved.

    • For a new site collection , the name, URL, type of site template will need to be determined.

  • For entire segregation process a default set of parameters should be motioned such as minimum version to be migrated such as last 10 versions. And Only on demand this parameter should able to be overridden for any given Source Object to be migrated.

  • The segregation export and import should support entire set of metadata, version history, file status as is (if checked out if possible) , user permissions configuration.

The segregation should also support consistent, as-is migration of data from source to target.

Design Constraints and Decisions

Implementation Approach:

 

Site Collection Creation and re-parenting see me other blog.
Locking the Exporting Site Collection see my other blog.
Export and Import API call specifics see my other blog.
Drawbacks of current List Export and Import Content Migration APIs see my other blog.
Hot to programmatically copy Web Level, List level and List Item Level Security Information see my other blog.

Thursday, March 24, 2011

SharePoint 2010 Migration

 

What am I blogging about?

Back in 2007 I did the MOSS 2007 migration with great success, that this year I am back to perform SharePoint 2010 migration, with several Web Applications worth TBs of data with several customizations. I want to use this blog as main page to start capturing major steps and tit-bits of  my findings.  I will try to capture the details in an order so that you can use it as a guidance for your migration.

Disclaimer

Whatever I can post here are general information relating to the topic and are provided as general motive of sharing with the community.

Steps in the order

Blow are major steps as I approach and for each I will be including sub activities and detailed blog for each such topic.

  1. Why to migrate to SPS 2010?
  2. Set up your development environments.
    • If you have very simple sites with no customizations, or if you already have your development/test environment then you are covered.
    • Otherwise your step step should be getting your development environments setup for both MOSS 2007 and SPS 2010 platforms.
  3. Simulate your web application(s).
    • If  your web application are running on SSL here is how to implement SSL in development, see my other blog here.
  4. Perform Analysis
  5. Preparation for Migration
  6. Migration Design (Coming soon…)
  7. Migration Implementation(Coming soon…)
  8. Migration Testing(Coming later…)
  9. Deployment(Coming later…)

What is pre Upgrade Checker report and what it is not

 

[This post is part of my main blog post on SharePoint 2010.]

The Pre Upgrade report captures three different levels of information:

  • Farm level information
    • OS Level
    • SharePoint Farm topology
  • Application level configurations
  • Content level State information

The context of Pre Upgrade report run is under the context of what if we were to perform an In place upgrade in the same farm MOSS 2007. 

If your MOSS 2007 farm OS is Win 2003 or 32bit,  you will see OSPrerequiste is failed. Since you are not going to be using the same farm and will not be doing the in-place upgrade this is attribute status is not applicable.

More to come…

Developing Sandboxed Solution in SPS 2010 Tips:

 

Here I will be collecting all the relevant information that would help us deal with development and deployment of  Sandboxed Solution for SharePoint 2010.

Design
  • Ensure the API/Class you intent use are available in Sandboxed solutions supported framework: Check the specific API/Class in MSDN. Note that MSDN has specific flag to denote if the specific API is available in Sandboxed solution.

                    image

 

 

Development
  • In order to ensure proper development copy the SharePoint dll locally only during development, later take it out to deploy….
Deployment
  • More to come…

Tuesday, March 22, 2011

Implementing SSL Certificate for IIS Sites in Windows 2003 Server for Development Purpose

 

Scenario

You have Windows 2003 server (x86 or x64) with IIS 6.0, this is your development server, you have to test several of your web sites with SSL and all of these web sites happen to be on same domain name such  as site1.mydomain.com, site2.mydomain.com, site3.mydomain.com …..

Disclaimer

I am not a Security/Certificate expert, but in this below blog I want to share my steps that have worked very well for the purpose of development to implement SSL certificates using SelfCert tool.

What can you do?

Instead of assigning individual certificates you can choose to implement wildcard certificates. such as getting certificate created for *.mydomain.com.

You can use SelfCert utility which is part of IIS 6.0  resource Kit tools.

You can use SSL Diagnostic utility which is part of IIS  6.0 resource Kit to finally validate the certificate assignments to your site.

How to implement wildcard Self Certificate in Windows 2003 server with IIS 6.0?
High level steps:
  1. In IIS create all your web sites (Site1,site2,site3….)
  2. Use Selfssl to create wildcard certificate and assign the certificate to given existing web site on your IIS.
  3. Then export the certificate along with private key to .pfx file.
  4. From your local machine certificate store, import the certificate in to Trusted Root Certificate Authority.
  5. From IIS, for each of your Site, assign your newly imported wildcard certificate.
  6. From command prompt assign securebindings for each of your site.
  7. From your client Browser, add your wildcard domain name as trusted site.

 

Step 1: Create IIS Sites

Create your IIS Sites from the IIS first. You don’t have to assign host headers at this time. We will cover the host headers later.

Step 2: Create Certificate

First download and install the IIS Resource Kit.  The utilities you choose will be installed at <SystemDrive>:\Program files[(x86)]\IIS Resources\

As first step lets first create a wildcard certificate for your domain name “*.mydomain.com” for example. 

We will use the selfssl tool to create a wildcard certificate against any one of the IIS site. (We will apply the certificate to all sites later). Go to command prompt and navigate to the folder where the Selfssl utility is stored. You can try SelfSsl /? to see all the options available.  Follow below syntax:

<SystemDrive>:\Program files[(x86)]\IIS Resources\>selfssl.exe /N:CN=*.<mydomain.com> /S:<IISSiteID>

Where substitute <mydomain.com> with your common domain  name, and for <IISSiteID> substitute IIS Site ID as displayed in the IIS manager Identifier column. (Default site is always 1, user created sites will have large number)

image

Above step creates an wildcard  certificate against your given site and stores the certificate under the Local Computer >Personal store.

Lets check this out:

From the command prompt run MMC. Add snap-in for Certificates, and choose My Computer.

image

 

image

Now navigate to the Console Root>Certificates (Local Computer)>Personal>Certificates. Here you should find your newly created wild card certificate along with the Machine Certificate and any other personal certificates.

image

image

 

Step 3: Export the certificate

Now lets export this certificate  out along with the private key, so that in the next step we can import in to the Trusted Root Certificate.

You can export this certificate from two different spots. Either from the Certificate management console that we opened in the above step to verify or from the IIS manager over the IIS site where we had created the wildcard certificate against.

From either spot you can launch the Certificate Export wizard.

From Certificate management console, you can choose your wild card certificate, right click, All Tasks, Export.

image

Or from IIS, right click over your site that you have used for selfcert command, Directory Security,  Click on Server Certificate and choose “Export the current certificate to a .pfx file.

image

Choose a file name and local folder where you want to exported certificate to be saved.  In the next step, provide password to protect the Certificate as you are also exporting the Private Key.

image

Step 4: Import certificate to Trusted Root Certificate Authority.

Now switch back to the Certificates management console. Navigate to the node “Trusted Root Certification Authorities>Certificates”.

image

From the Certificates node, right click and choose to import certificate.

image

Now choose the above saved certificate file to import, enter the password entered above to encrypt the certificate file.

Next choose to import the certificate as below.

image

Next confirm a successful import.

image

Step 5: Assign wildcard certificate from IIS

Now switch to IIS MMC. For each of your IIS sites, assign the newly acquired selfcert generated certificate. Leave the SSL port as is and the default port as is. The sites may be in stopped state and that is fine at this stage, since all of the sites are using the same default port 80.

Step 6: Assign securebindings.

Prerequisite for this step is that you have already installed the IIS Administrative Scripts located as below:   (If not install from your Control Panel>Add Remove Windows Components>Choose IIS to reinstall the AdminScripts >

image

Now go to IIS MMC, note Identifier for each of your Sites that will require the new certificates to be assigned.

Go to command prompt and change directory to the above highlighted AdminScripts folder.

Enter following command for each of the IIS sites that you want the certificate is assigned.

cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:<host header>"

where host header is the host header for the Web site, for example, site1.mydomain.com.

After above steps are completed, go back to IIS MMC and start each of your sites.

Step 7: Add to Trusted Sites

From your development server browser, add your wildcard domain name as trusted site. (*.mydomain.com)

image 

Validation

From the installation of IIS Resource kit you will also get SSL Diagnostic tool installed.

image

Run the SSL Diagnostics tool. The tool will check SSL certificate for each of the IIS sites and provide report as below.

image

In the above screen cap, I have masked the domain names I had used, but you should expect to see your respective wild card domain name.

Next browse to each of your IIS Sites from the Browse and you should be able to see your site without any certificate warning.

Hope these steps will simplify your SSL implementation for the purpose of development

Things to consider beyond just SSL
  • Simulate SSL per site in your development environment.
  • Address your browse warning for mixed content if present.
  • Will update further if anything comes across my attention.