Monday, November 27, 2006

Microsoft Office Sharepoint Server 2007 (Beta)Setup ErrorsSetup is unable to proceed due to the following error(s):This product requires Windows Workf

When installing MOSS 2007 Beta2 on an SPS2003 environment during an upgrade attempt, I received the following error:

Microsoft Office Sharepoint Server 2007 (Beta)Setup ErrorsSetup is unable to proceed due to the following error(s):This product requires Windows Workflow Foundation Beta 2 (Build 3.0.3807.7 or later).Please refer to this readme file for instructions to obtain these pre-requisites. Correct the issue(s) listed above and re-run setup.


My action steps were as follows:

1. Remove .NET 3.0 framework using the Pre-released Microsoft .NET Framework 3.0 Uninstall Tool


2. Install Windows Workflow Foundation Runtime Components Beta 2_2(EN) for x86.exe


After I completed these steps I was able to install MOSS 2007 Beta 2.

Saturday, November 25, 2006

The Value of Having a Separate "Admin" Portal

Sharepoint portal deployments can be complicated to manage. They can include several customizations that make restores, upgrades, and day to day maintenance more difficult to perform.

Think about all of the data that is necessary to maintain in order to effectively manage Sharepoint.

Contact information
Invoices, subscription information
License compliance reports
Hardware (make, model, sn, RAID, tech support information)
IP addresses
Port numbers
SSL certficates
Users, passwords
Portal area security hierarchies
Group memberships
Service identities
IIS host headers
IIS app pool identities
Area/site templates
Unghosted pages
Branding, modifications to OWS.css, Menu.css, SPS.css, ..OWSPERS.css, OWSmac.css, OWSnocr.css, Paystub.css
Custom image files
Custom animation files (swf files)
Third party add-ons
Custom web parts (dwp files, assembly files, aspx files)
Custom javascript e.g. custom_owj.js
Data view, custom data sources to line of business databases
Custom security, site groups, ad groups, audiences, web part
Connected web parts
Dependency information
Datasources pointing to Sharepoint content db
Linked servers
Instruction documents
Backup and restore procedure
Support procedures
Log files
Code templates
Branding templates

One solution I have found to be very helpful is to deploy a separate Sharepoint portal with the sole purpose of maintaining administrative information. I like to keep it vanilla so that I can quickly restore it independently from the main portal(s). I find that it is really easy to lock down the portal when you are only going to allow administrators to access it.

Tuesday, November 21, 2006

SQL Server 2005 install error 70233

While I was installing the SQL Server 2005 Prerequisites I came accross this error:

"Errors occurred during the installation: Beta Components Detected. Error 70233 installing .NET Framework 2.0."

After running the utility provided by the link below, the installation was able to successfully continue http://go.microsoft.com/fwlink/?LinkID=47598

Tuesday, November 14, 2006

Upgrading to Sharepoint V3: The "Other" Option

Microsoft offers four options for upgrading SharePoint V2 to SharePoint V3. These approaches describe how to take your V2 Portal or Site Collections and upgrade the underlying software to V3.

In-Place Upgrade
Gradual Upgrade
Gradual upgrade for Shared Services
Content Database Migration

To view detailed comparison of these options, visit Microsoft TechNet's Determine upgrade approach [Office SharePoint Server].

I want to also introduce another option. In fact I like to refer to it as the "other upgrade option." The way I describe this is that you install a fresh V3 portal and you recreate manually, then migrate data and content. This allows you an opportunity to first re-think the design of each part of the new portal, instead of automatically inheriting the limited configurations that you have in V2.

In some cases, I think that running an upgrade can be a mistake. As you know, performing a software upgrade to V3 doesn't automatically result in a robust V3 environment that suddenly fulfills all of your needs and desires...it just puts your same old portal on new software that happens to be capable of doing more. You still have to due necessary diligence to figure out how you are going to leverage the new functionality to meet business needs. This is a manual process. There are no short cuts. And, in some cases, by upgrading content from V3 to V7 you are actually creating more work for yourself.

Implementing new portal technology is kind of like traveling from point A to point B. Point A represents the portal concept and design that you arrive at after you analyze the business requirements, draw scribbles on the whiteboard, and have some meaningful discussions about the portal you are going to build.

A (idea) -----> B (reality)

Point B is reality. It is the end product; an actual, tangible Sharepoint 2007 environment configured the best possible way to resemble your concept.

And, the V2 portal is simply an outdated Point B.

Consider too, that the business requirements that drove the V2 portal probably have become more complex. V2 users may be wanting more sophisticated functionality by now. If time and budgets allow, don't automatically assume the limitations of a V2 portal when the subject of Sharepoint V3 comes up. Implementing V3 may be a great opportunity to re-engineer the portal solution and selecting the "other" upgrade option of redefining and creating your V3 portal from your ideas instead of from your V2 portal may result in a better solution.

Blog Archive