Impact of SharePoint Designer Free Distribution

This week it was announced that SharePoint Designer 2007 and future versions are now freely distributed.

Announcement

Download

The developer community was quick to applaud the news since this is a useful tool, but I assume also because getting software purchases approved in the current economy is difficult at best even in stable companies.

The news however brought a different set of comments from the system administrators and IT management folks who are worried about what the ramifications will be. They are right to be worried. Many companies are already struggling with governance and end user site ownership issues. With that in mind I think it gives them that much more incentive to get their policies, procedures, and training plans in order.

From a Program Management perspective, I think it is critical to the platform to enable end user groups to design, manage, and interact with their own content. That includes maintaining their own access control lists (ACLs), libraries, lists, and design their own workflows. I see SharePoint Designer as an extension of the platform, not much different than MS Word or Excel. Site Owners and Designers need to be able to manage this in most situations.

In a medium to large organization it would take an army of IT team members to manage this for every group, it is just not feasible and not the purpose of the SharePoint platform.

So how should you proceed?
Governance – Address custom design and development in your Governance plan. Determine who can have it, and what it can be used for.

Training – Address its use in your training plan, and make sure that Design and Developer resources are available. Perhaps you can pick up a copy or two of Professional Microsoft Office SharePoint Designer 2007 (Wrox Programmer to Programmer).

SharePoint Designer Collaboration Site – Provide site owners with a place to collaborate and provide guidance. You can include samples, links, and FAQs to help them.

Through proper governance you can help guide their decisions and enable their success. Their success and approval leads to the success of the platform in your organization.

What can be done to prevent use of Designer?
Installation – For now you can look at local computer policy and prevent installation of unapproved software. For people in companies that already do this, they know that it takes a lot to manage that.

Security – You can also review site security and make sure that the appropriate set of users have access to make changes.

Disable at the Site Level – There is some work in the community right now to come up with a solution to prevent specified sites from being changed or customized with SharePoint Designer.

UPDATED: John Ferringer and Brian Farnhill have posted a Beta for the project, setup as an HTTP Event Handler to block SP Access. It can be found here: No SPD HTTP Event Handler.

What is your response to the news? Excited, terrified? Post a comment!

SharePoint Active Directory Migrations: Users and Servers

I have been hearing more and more questions recently about Active Directory migrations with relation to SharePoint deployments. It could be from some organizational changes, or because business managers just like to keep people busy.

When I had to go through this process during the summer of 2008 I found much less information that I expected so I had to work through some of the problems myself. Here is the result of what I found. Hopefully it can assist other organizations in the process.

I have broken everything into five steps; Prep, Server Move, Service Updates, Migrating User Accounts, and Post-Migration Validation.

SharePoint Supports Multiple Domains
One thing I want to point out is that SharePoint works great in environments with multiple domains. The only prerequisite is that proper domain trust is in place to support authenticating users across the domains.

If the users will be migrated slowly over a period of time services should go uninterrupted. It is possible to keep the servers and services running on the old domain until all users are migrated, or move the servers and services early on and then run the user migrations in batches over time.

Preparation
Before any major system changes it is always a good idea to perform and validate a fully system and content backup. It is also essential to ensure that you have a non-domain account available on the server that you can use to access the server after it has been removed from the domain.

I would also make sure that all of your site profiles are currently up to date. To do this run the following command:

stsadm -o sync -excludewebapps {Web applications} -synctiming {schedule} -sweeptiming {schedule} -listolddatabases {days} -deleteolddatabases {days}

TechNet Documentation for STSADM –o sync: http://technet.microsoft.com/en-us/library/cc263196.aspx

Server Migration
Migrating the server from the old domain to the new domain is handled through regular computer settings and is not SharePoint specific. If you do this manually, keep in mind that you will need an administrator account on the server after it is removed from the domain in order to join it to the new domain.

There are some good Active Directory migration tools from vendors like Quest software that can automate the move process. In addition to the remove and joining to the new domain it can migrate the user profiles and add in a list of domain users to the local Administrators group.

Update Services
Migrating the farm services is pretty quick and easy. There are commands in the stsadm tool that allow you to update all of the accounts used within the services and IIS application pools.

Run the commands and then reboot the servers so that all services load under their new identities.

The following MS Support link provides an overview and examples. http://support.microsoft.com/kb/934838

Migrate User Accounts

stsadm -o migrateuser -oldlogin {domainname} -newlogin {domainname} [-ignoresidhistory]

The ignoresidhistory input at the end is optional. The SID is a guid for that user account, and a reference to it is stored in the SharePoint profile. If the accounts were migrated correctly the SID history should be maintained.

By default the migrateuser command will validate that the oldlogin and newlogin have the same SID. For cases where the SID history was not maintained, you will receive an error about the SID not matching, and you will need to supply this input.

The validation is helpful in preventing incorrect account migrations where there are two users with the same username. This happens frequently with common names like Smith, Johnson, or Garcia.

The command needs to be run for each user you need to migrate. This can be done user by user, or in large batches. However you run it, make sure that you have access to the results so that you can review and correct the exceptions.

TechNet Documentation for STSADM –o MigrateUser: http://technet.microsoft.com/en-us/library/cc262141.aspx

Post-Migration Validation
After the services are moved, standard test cases apply. Make sure that the main site collections load, user permissions are maintained, and that search queries return accurate results.

If you run MOSS you will want to setup the profile import to the new domain. This will ensure that updates are pulled in over time.

You can use the profile lookup form in the Shared Service Provider to search for profiles on the old server. Use a Wildcard “*” after the domain name to pull back all users for a given domain.

If you want to look at the site collections and see how many accounts are on the old domain user can query the Content Databases. You will need to run the query against each Content DB.

Disclaimer: Accessing production databases even just to query may not be a good idea. Do this at your own risk.

select distinct tp_login, tp_email, tp_title
from {ContentDBName}.dbo.userinfo
where tp_login like ‘{Old Domain}%’ order by tp_login

Thoughts on Delicious and Community Relevance

I have been using Delicious for a few years now. What initially interested me was the concept of having access to my bookmarks from any computer. That means from my home computer, office computer, or when logged into a server trying to fix a problem. The tagging part was secondary, though it has grown to be an essential part of the feature set.

I have started to use the tool a bit more lately and have found that I am also using it as a search tool. Not only will it return any items that I have previously tagged, but it will also bring back results from the overall network. The results include a count of the number of other members that have also tagged the page. The value here is that you can get a good indication of which pages were deemed relevant to the community. By starting with those pages, you are much more likely to find what you are looking for.

Do you use it in this manner? Have any other tips? I would love to read your comments!

The Importance of a Content Syndication and Aggregation Plan

One of the keys to managing a successful SharePoint implementation is having a Content Syndication and Aggregation Plan. Address the plan early in the design process to avoid more difficult changes later in the life of the system.

The plan should cover:
Content Locations – Helping users develop a methodology for where to locate content (Centrally / Group Level) and how to aggregate it when needed.

Role of Content – Is the content to be consumed (read) or updated? Content that needs to be modified from remote locations needs to be handled differently.

Content Types – By thinking about the content and content types early on in the process data can be addressed in a consistent way which will make it easier for people to understand and easier to aggregate the data thanks to common structures.

Why is a plan needed?
As Site Collections continue to grow in scope and size it will become clear that different groups need to work with the same data or that the same data has relevance in more than one context. The promise of collaboration tools like SharePoint is that they can deliver targeted information in specific places instead of making users visit dozens of different sources. One of the frequent complaints that I hear is that related data is in too many disparate sites, with another being that files are copied to multiple sites where they are consumed.

What are the methods for syndication and aggregation?
Really Simple Syndication (RSS) – Most people have a good understanding of what RSS is and how it can be used to pull content into the sites, but not all realize that they use it to share data within SharePoint sites.

As the full name suggests it is Really Simple, but that also means there can be some limits to what it can be used for. I tend to use it for communicating simple data like News, Announcements, and of course Blog updates.

Web Parts – With this approach web parts are configured to include data from one or more sources for display somewhere else. This can be done with a DataView configured in SharePoint Designer or with the Content Query Web Part (CQWP) if you have MOSS. One limit with these two options is that data must exist within the Site Collection; it cannot access data outside of that boundary.

Another option is a custom web part or a third party “Rollup” web part that provides similar functionality but offers the ability to access the data via a web service call opening up the data from any accessible SharePoint site.

Document Link Content Type – If the “Document Link” content type is added to the document library, it will enable the sites user’s to put a shortcut/link in the document library that points to the document’s source location. This is a simple, but effective way to list documents in more than one library without the storage overhead or the confusion around which is the correct location to edit the document.

Publishing – The MOSS Publishing features support configuring a Custom Send to Destination within the library’s Advanced Settings. This provides a mechanism for pushing documents from a source to a destination library which really comes in handy with a document control process that separates the Work in Process (WIP) library from the document library users consume information on.

Content Synchronization – There may be instances when you need to be able to synchronize data or files to another farm or site collection. Examples would include pushing content from an internal system to an extranet or visa versa. There are a few third party solutions that can help facilitate this, or a custom solution can be developed.

Examples of where it can be used.
Here are some common examples that I’ve run into:

  • Company Holidays and Calendar
  • Common Company Forms
  • Policies and Procedures
  • Project Information and Summary Status Reports

Summary
SharePoint has a great foundation for content syndication and aggregation. By developing your plan early in your design and communicating it to your community it will help shape design decisions and educate users on how to maximize the effectiveness of the content sharing. All of this will help avoid user frustration and lead to wider end user adoption and satisfaction with content that proves to be much more portable.

Buy versus Build

A discussion broke out on the MSDN/TechNet SharePoint Forums this week that started to approach the subject of build versus buy. It is something I have had to put a fair amount of thought to in the past so I decided it might make for an interesting blog post.

As a developer, I enjoy developing. It is always fun to dig into code and solve a problem or fill a need. Unfortunately I don’t get nearly as much time to develop as I used to or would like. It ends up being something I do between meetings, on weekends, or in support of a project when the other developers are not available. As I’ve moved through the roles of developer, team leader, architect / program manager I have had to look at things from different angles including that of what is best for the company or the users the solution is being deployed for. Sometimes those personal goals and enjoyment have to be set aside in support of the company’s and users’ best interest.

One of the main trends of computing over the past 10+ years is the move towards interchangeable components, services, etc that can be stitched together offering reuse and decreasing the total cost of managing systems. SharePoint is a great example of this as a platform that has a rich market of third-party vendors. There are 100s of available solutions, web parts, etc that are publically available.

Here are some considerations when evaluating whether to Buy or Build solutions.

Requirements – Is there a solution available that meets the requirements? Is there something close enough to consider as an option? If not, and its needed then its clear you would have to develop it.

Initial level of effort – Do you, or does somebody on the team have the skills and know how to develop the solution or is this a learning opportunity? How long do you expect it to take? If it is full of unknowns or if the projected cost based on a standard rate ($50 an hour?) comes to 80% or more of a commercially available solution it probably isn’t something that should be custom built.

Are there other things that are a better use of your time? The last few organizations I’ve worked with I’ve had a running backlog of projects averaging two years. It is normally easier to purchase components than it is to add to the headcount. Purchasing components or solutions makes it that much easier to deliver value quickly.

Ongoing maintenance and support – Do you or does the group have the time to support the solution going forward? You may have time now, but if you squeeze it in what happens when they come back for changes or you need to upgrade? Will you have time to work on it? You can rely on the vendor for this in most cases if you purchase support for the solution.

On the flipside, make sure you take into account the vendor’s stability and history and make sure that they will support the solution going forward and/or still be around. I have made the mistake of purchasing a solution from one company that sold me a dead-end product that was replaced.

Quality / Grade – Do you, or your team have the skills to meet the needed quality and grade of the solution? In most cases the commercially available solution has a team supporting the development effort to include qualified quality assurance professionals.

Budget – Do you have funds available for the purchase. In some cases there just is not money available, we are in a recession after all, but smart businesses will find the funds if the solution does add value and save time. Mature organizations probably understand this a little better, and therefore tend to have larger budgets to support the purchase of technology.

Summary
By taking these considerations into account it will help you make decisions that add value to the organization and its end users.

Finding Success with SharePoint Deployments

Finding success with SharePoint or any other collaboration software can be a difficult thing. It has less to do with the technology than it does the people and the way its implemented. Its not that people have bad ideas, they may just underestimate the amount of effort it takes to reach the promised land. There is no silver bullet or application that you deploy and it just magically solves all of the organization’s problems. In many cases the software is deployed as part of an formal or informal effort to breakdown longstanding silos within the organization. Breaking down those silos is difficult and that road is filled with hazards.

A good first step is to clear identify and validate the goals of the implementation and get an understanding of what the expected level of effort is to reach those goals.

Easy Win or Easy Implementation?
The best way to get an easy win or have an easy implementation is to install SharePoint as a workgroup solution. Its very easy to do, and if based on Windows SharePoint Services (WSS) it can be done with existing equipment. Each department or workgroup can then do whatever they want and get as little or as much localized value out of it as they want. The people may seem to be happy with that, but there is a real limit to the amount of success and productivity. Also, it does nothing to promote sharing and collaboration throughout the entire organization. In fact it further reinforces those silos.

Enterprise Needs Governance
If you talk to any long time SharePoint architect or evangelist one of the primary topics is Governance. Its not just a buzzword, it is the single most important determining factor for success in a large organization. It is the glue that holds everything together and gives you the ability to manage the environment without it breaking down into petty fiefdoms. Getting agreement is never as easy as making an independent decision and then acting.

In an enterprise deployment it should support localized management in support of global standards. Just because Governance is in place does not mean that everything must be managed centrally.

Here are some suggestions
– Get executive sponsorship. Organizational change cannot happen without executive sponsorship. State the case with realistic benefits and get buy in.

– Involve as many stakeholders as possible. Like any change people are more likely to adopt it when they have a say in what is done. Not everyone will like every decision, but hopefully they will feel good enough about their involvement that they will participate.

– Address Governance from the start. You cannot easily retrofit these ideas or policies into an established system. The change would be costly and the need to retrain everyone pretty severe.

Benefits to Enterprise versus Workgroup Solutions?
Enterprise deployments benefit organizations by supporting cross-functional collaboration. It also provides a platform for some of the social enterprise capabilities such as central profiles fed with data from sources like Active Directory, HRIS Employee Data, and other data sources particular to the organization. These tools can help make people more productive, but also help to find internal resources and subject matter experts.

Another benefit is that you are more likely to see funding for integration efforts into other enterprise systems such as Business Intelligence (BI), Enterprise Content Management (ECM) or Business Process Management (BPM) solutions. Being able to leverage these other integrations should more than make up for the lack of control the individual organizations’ are asked to give up.

SharePoint Customization Policies and Change Control

This post will cover different forms of customization, discuss the need for IT policies that support customization, and then provide a recommendation for how to manage the customization through change control processes.

What is considered customization?
There are different types of customizations and different ways to apply them. They can include custom styles, MasterPages, Web Parts, Custom Forms, Site Definition or even applications built on top of the API.

Bad customizations are applied manually by adding to or altering system files on the server. These changes are not saved into the configuration database which can cause problems when applying system patches or upgrades. It can also make it much more difficult to add an additional server to the farm as those changes have to be manually applied again. Therefore this should never be done in a production environment.

Well built customizations are deployed using SharePoint’s robust deployment framework for Web Parts and Solutions. This not only produces repeatable results, but it also helps keep multi-server farms in sync and allows those customizations to be pushed out automatically to new servers joined to the farm. This method is also much less likely to produce problems when applying patches, updates or even upgrades.


SharePoint Success without Customizations?

While I believe strongly that there is a lot of value in the base solution, I think that SharePoint is set apart by the expandability and integration options. This is what can take it from an ad-hoc workgroup solution to an enterprise platform.

Too many IT shops have taken a No Customization stance when it comes to Enterprise Software. They will quote ballooning implementation costs, reliability of the changes or the difficulty that exists in performing normal version upgrades. Many of these are valid issues to some degree with packaged software, but it is not an irrefutable law. SharePoint is a platform that is intended to be molded to meet an organization’s needs, and customizing it is not the same as rewriting core sections of an ERP system.

In more than on instance I’ve seen SharePoint workflow projects move forward with the decision that no “code” can be written, which means they cannot use Visual Studio or create custom actions. The alternative is for them to use SharePoint Designer to create those workflows. While that may be a good idea for small or simple workflows, there are limitations, but even worse there is no reusability in their work. If something similar is needed somewhere else it has to be recreated.

By making a unilateral decision that no customizations can be made, you are handicapping the system and limiting the value it can deliver. Business and IT leaders need to consider this before making any policy changes.

What about Change Control?
In organizations where there is a Change Control policy in place, it is important to categorize the types of changes. I would advocate grouping changes into the following groups Content and Site Configuration, Packaged Code, and System Level Changes.
Content and Site Configuration – This includes using the toolset to add and update content in lists and libraries along with the creation and design of Sites, Lists, and Libraries. These tasks should not require approval.

Packaged Code – This includes the installation of custom or third party web parts, solutions, workflow actions and templates. Since these packages can possibly cause harm, and should be part of the system’s documentation, it should pass through the Change Control process.

System Level Changes – This includes adding an additional server to the farm, changing a servers’ role, reconfiguring personalization features or rebuilding the Shared Service Provider. These changes can possibly have a huge impact on the entire system. It is important to capture the details of those changes in the documentation, and also make sure that all stakeholders are aware of the changes being made.

%d bloggers like this: