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.

Tuesday, October 24, 2006

Links: SharePoint

All Versions
Microsoft Office SharePoint Server 2007 products comparison download
Penny Coventry: Sharepoint Version Table
Heather Solomon: CSS Quick Reference
Heather Solomon: CSS Reference Chart for Sharepoint 2003

Version 3
Microsoft TechNet: Office SharePoint Server 2007
Microsoft TechNet: Upgrading to Office SharePoint Server 2007
Microsoft TechNet: Determine upgrade approach (Office SharePoint Server)
Microsoft Office Online: Microsoft Office SharePoint Server 2007 Frequently Asked Questions
Jason Medero: WSS V3/MOSS 2007 Upgrade and Migration from V2: Part 1 of 2
Jason Medero: WSS V3/MOSS 2007 Upgrade and Migration from V2: Part 2 of 2
Joel Oleson: Troubleshooting & Logs during a WSS/MOSS Upgrade
Shane Young: Upgrading from SPS 2003 to MOSS 2007 Beta2 TR using the gradual approach
Jonathon Frost: Preparing for a SharePoint Server 2007 Upgrade
James Henry: SPS 2003 to MOSS 2007 Upgrade Issues
William Baer: Understanding PRESCAN.EXE in MOSS 2007
Bill English: Moving SPS 2003 Databases to new SQL Servers
MSDN: Best Practices for Ensuring Application Reusability and Upgrade in Windows SharePoint Services
Joel Oleson: Best of... Upgrade and Deployment Guides for WSS v3 and Microsoft Office SharePoint Server 2007

Version 2
MSDN: Branding a SharePoint Portal Server 2003 Site: Part 1, Understanding the Use of a Corporate Brand
MSDN: Branding a SharePoint Portal Server 2003 Site: Part 2, How to Apply Your Own Corporate Brand
Dr. Dobbs: Sharepoint Web Part Development

Version 1
Microsoft: How to Create a Personal Dashboard in SharePoint Portal Server
Microsoft: Programs That Cannot Coexist with SharePoint Portal Server
Microsoft: Accessing a Workspace Using HTTPS Does Not Work, Dashboard Error -2147221499
Microsoft: Setup FAQ and Troubleshooting Guide
Microsoft: IIS Lockdown Tool Affects SharePoint Portal Server
Microsoft: Errors When Antivirus Software Scans Web Storage System
Microsoft: Indexing Web Sites on the Internet
Microsoft: Portal Displays Incorrectly When You Use FQDN
Microsoft: Required Properties Not Enforced During Bulk Check-in
Microsoft: SharePoint Portal Server and Storage Area Networks

Monday, October 02, 2006

Using the Web Service Interface of Windows SharePoint Services (2003)

Web services available in Windows SharePoint Services:

Administrative methods for managing a deployment of Microsoft Windows SharePoint Services, such as for creating or deleting site collections.

Methods for working with alerts for list items in a SharePoint site.

Data Retrieval Service
Methods for retrieving schemas and data.

Document Workspace
Methods for managing Document Workspace sites and the data they contain.

Methods for returning forms used in the user interface when working with the contents of a list.

Methods that enable you to create and manage picture libraries.

Methods for working with lists and list data.

Methods that enable you to create and manage Meeting Workspace sites.

Methods for working with Windows SharePoint Services security.

Site Data
Methods used by search services to extract and crawl data from SharePoint sites.

Methods for returning information about the collection of site templates on the virtual server.

Users and Groups
Methods for working with users, site groups, and cross-site groups.

Methods for working with file versions.

Methods for working with views of lists.

Web Part Pages
Methods to send information to and retrieve information from XML Web services.

Methods for working with sites and subsites.

SharePoint Products and Technologies (2003): GetUserProfileByName(String) Method

SharePoint Products and Technologies (2003) SDK Documentation

GetUserProfileByName(String) Method.
The GetUserProfileByName method of the UserProfile service gets user profile property information by account name.

Parameter: AccountName
The account name that specifies the user profile property.
Return ValueMicrosoft.SharePoint.Portal.UserProfiles.PropertyData that contains the user profile property information.

Exception Type:
UserNotFoundException Class.
Condition: User is not found.

Platforms: Microsoft Windows Server 2003.
Code Access Security.

Friday, September 29, 2006

Sharepoint revelation: it can leverage SOA, it can be a composite application

What happens when business users are demanding a single user interface? What happens when they want their data to be truly integrated and relational? What happens when all the other applications fall short?

The answer is to bring together data and functionality from other systems and create one single composite application.

Microsoft Sharepoint is a great architecture to leverage for this purpose. It offers an excellent portal and web part infrastructure. A solid authentication and security model can easily be achieved. It is easy to recover Sharepoint web applications. Sharepoint is scalable. Customizable look & feel and navigation...its there. In short, Sharepoint addresses all the aspects of web application overhead that may currently prevent you from being able to focus on and deliver those things that the business units are demanding.

Sharepoint is robust, but often times businesses require functionality that out of box web parts cannot achieve because these web parts tend to function at the "surface." In other words, unlike an off the shelf software application such as a CRM system which may store user data in a relational database, the back end data model for Sharepoint user data is relatively flat. Sure, you can create web parts to view external data from the other systems, but a lot of times business units want more than that. They want their portal to "be" the other application. This tends to be the line in the sand where many Sharepoint implementations stop. However, this boundary represents a new frontier for some. This is where you start thinking about how you can build a composite application using Sharepoint.

Building a composite application is all about breaking down functional components and being able to use them independently. For example, the act of adding a new contact record to a crm system. This is a simple, but vital action. Do you need an entire CRM application to do this? Who says you need to be in the CRM system to create contact records? Break down the programming and logic behind the act of creating a contact record, package this as a web part, and deploy it to Sharepoint. In this example you would keep your CRM system in place and extend the existing data and functionality to a Sharepoint web application by way of web parts.

On a broader scale, take a look at the various business applications in your environment and make a list of the functional components that each one is comprised of. Imagine what it would be like to have all this functionality in one single UI. The bulk of the effort to achieve this in Sharepoint is making each functional component available independently from its native software application and creating web parts for each of these components. Once you have done that you can use them througout the Sharepoint web application.

The ROI for a project such as this will be high in situations where you are buying user licenses and maintenance for your other business applications and when the users are only actually using a portion of the functionality that is being purchased. This is where a composite application project has some real value.

Blog Archive