Getting ready to head out to SharePoint Saturday DC tomorrow. Anyone interested in following the fun can tune in for live updates on the following Twitter Feeds:
Or by following the #spsdc tags http://hashtags.org/search?q=%23spsdc
In my talks with end users about application features and solution they are interested in, I often hear people mention mobile device access. Two years ago the request surprised me because the mobile devices made browsing cumbersome and offered limited features. In the time since both the devices, and the software running them, have advanced quite a bit to the point where there is a solid offering.
Many of companies are lagging behind though and are not yet offering services to those devices. Even in many blackberry environments there is little application usage outside of email. In those same environments there is soften little or no access for any other devices.
Now that some of the top tier devices are supporting Wi-Fi it would be great if organizations would extend secure access to the wireless devices over Wi-Fi without the need for VPN software. As technologies continue to develop, connectivity is going to become that much more important.
Does your organization support mobile devices? If so I would like to hear your feedback on how well users embrace it and any other lessons learned. You can leave a comment or connect with me on Twitter @next_connect.
One of the great things about SharePoint today is the incredible traction that the platform has gained. The depth and range of solutions now offered by vendors along with open source solutions offered by the community really is amazing. It was a different place when I first installed SharePoint Portal Server 2001 back in early 2002.
Browsing the CodePlex I often feel like a kid in a candy store. So many great solutions, I cannot wait to install them all! Well not so fast, it might be a good idea to take a step back and consider the consequences.
Deciding What to Install
One key to maintaining a well run environment is to have a process in place to review, approve, and manage customizations. This should be part of your formal governance plan, but if you do not have one do not let that stop you from looking at this particular topic and working out some plans.
Special care should be given to non-commercial solutions. They should always be tested in a non-production environment before being deployed to your production environment. When downloading community code, be sure to take notice of who is contributing it and what the official release is. CodePlex for example does a great job of showing build info and release notes. If an item is marked as Alpha or Beta it probably has not been put through rigorous testing yet. If you want to use it then make sure you are comfortable with the risks and test it in your environment.
Your test environment should be as similar to your production environment as possible. You do not necessarily have to put it on the same quality of hardware, but the configuration should be similar. It is critical that the patch levels are the same. On this note, you should be testing any KB Patches, MS Cumulative Updates, or Service Packs anyway.
Make sure that the test environment also includes the full catalog of Solutions, Web Parts, and other customizations. This is important because it is possible that one might conflict with another. Unit Testing is not enough, you will want to see how it will react and interact with your environment.
Potential Problems or Conflicts
Depending on what functionality the solution provides, the problems or conflicts can range quite a bit. Knowing what is installed is a good start.
While there is a chance that something could break independently, most of the issues I have seen came from trying to migrate, patch, or upgrade a site.
Site Migration – When migrating a site from one environment to another, it can be a pain to find out half way through that you need to install additional site templates or web parts on the target server.
Patch – When completing the installation of a Patch, Cumulative Update, or Service Pack you normally have to finish the upgrade by running either the Configuration Wizard or the PSConfig command line app. This can be a pretty stressful exercise, and no fun comes from seeing it fail along the way. I have had customizations cause problems here, particularly when changes were made directly to the web.config file as some solutions require. Having your documentation on hand will help you get through the mess and cut down on the time it takes to complete the upgrade.
Future Versions – You also need to consider the likelihood that the solution will be maintained going forward. When I made the jump from WSS 2.0 and SPS 2003 to the current version WSS 3.0 and MOSS many of the solutions I had been using did not make the jump. Some of it was because of the code base changing from .NET version 1.1 to 2.0 and some of it was because Microsoft added parts of the functionality to the platform so vendor no longer wanted to support the products. End users are not necessarily going to care why they do what they used to do, they will only care that they cannot do it. Mitigate the risk by communicating to the stakeholders the potential problems.
It has already been noted that Service Pack 2 will include an upgrade readiness check to help identify any potential problems upgrade to the next version. I would recommend taking the time to go through this check after SP2 is installed, and then checking it again after you install any new solutions before making the jump to the new release.
By putting together a plan to review, test, and approve add-on solutions you will decrease the likelihood of problems in your environment and decrease the time it will take to respond to issues when they do come up.
I have seen this error come up a few times, and reported frequently on the MSDN/TechNet Forums. Once the problem is understood, it is fairly easy to correct.
There are a few different pieces that come into play when a user clicks on the My Site link at the top of a MOSS page. The user goes through a centralized MySite.aspx page that acts as a redirect. A check is done to see if the user already has a My Site specified in their profile. If there is a site specified it sends them to the site, if the site is not specified it sends them through the site creation process.
On a couple of occasions I have seen the following error:
The file exists. (Exception from HRESULT: 0x80070050)
Troubleshoot issues with Windows SharePoint Services.
This happens because the user’s profile does not contain a valid path in the Personal site field. The user is then pushed into the site provisioning process, but since the site paths have to be unique, the process is unable to create a new site.
For some reason the profile field was reset or corrupted leaving it blank or filled with something like an error code or invalid statement.
To resolve this issue, you want to first validate the path to the user’s site. The path will vary depending on your setup and naming conventions, but it should be something like http://servername/personal/juser
Once you know what the valid path is, update the Personal site property to include the valid path. Ex. “/personal/juser”
To update the user’s profile:
What causes the error?
On a few occasions the cause could not be determined. Since it was easy to fix we didn’t spend a whole lot of time looking into the cause. The majority of the instances happened after an Active Directory migration where the user’s profile was migrated incorrectly.
When going through an account migration either through Active Directory, or in switching to something like Forms Based Authentication (FBA), make sure you migrate the user profiles using Migrate User. Additional information can be found on that topic at the blog post titled SharePoint AD Migrations: Users and Servers.
Looking at Technorati today I was surprised to see their results of some SharePoint related keyword activity.
I pulled a graph with “SharePoint”, “MOSS”, “Workflow”, and “Office 14” which is shown below.
It has been awhile since I’ve referred to it as MOSS, though 90% of the work I do is related to MOSS environments. I must be in the minority because the MOSS keyword is frequently used.
Looks like there has been a lot of press on Office 14 which is quickly picking up steam for a release sometime next year.
As we slowly inch closer to vNext aka Office 14 I have recently been thinking about some of the productivity and connectivity features I really wish Microsoft would concentrate on. I am pretty sure none of these are addressed in Office 14, but maybe it is not too late to start thinking about them for the next product cycle.
Presence and Modular Messaging
One of my current pains is centered on integration with various messaging services. Despite Microsoft’s best efforts MSN / Live Messenger never really took off and within the enterprise, Communications Server was just a bit too late to take hold. There really needs to be a mechanism for integrating with multiple messaging platforms. There are plenty of web applications that do this well, it is nothing new.
In my current environment Skype is the standard messaging tool. It is secure, operates very well internationally, and the price is pretty attractive as well. I have extended our user profiles in MOSS to include the Skype Contact information and written a simple web part to display status and connection commands. While that is all very valuable, it sure would be nice if we could use this to communicate online presence, or if it could be easily integrated into the presence actions through configuration. I am currently looking into the ability to extend that functionality with the Skype functions, but so far have not had much time to dedicate to that.
Users can currently add RSS to a page via a standard web part, but what I would really like to see is a true Enterprise RSS solution that supports subscription management, categories, the ability to share feeds with colleagues, and content based recommendations.
It would also be nice if there were web services or web parts that helped expose the data so that the functionality can also be integrated into site collections that support things like Communities of Practice.
SharePoint URLs have gotten too long. I frequently run into instances where URLs being tracked in SharePoint lists and menus are over 250 characters. This is a pain for end users to work with, but even worse if you try and save it in a SharePoint link field the value gets truncated.
Time will tell…
Time will tell what they end up adding to the platform, but I think these features would help to foster collaboration and information sharing across the organization.
I was recently asked to restore a site collection that was being hosted on an external provider’s network without any SharePoint patches installed. There were also some custom templates installed that had to be tested internally.
Bringing this site in took a little extra work. We couldn’t just restore the site collection backup into the regular production farm.
Update: – When I originally wrote this post I thought both servers had to be at the exact same patch level, but this is incorrect. The target server needs to be the same or greater.
To handle this, I went through the following steps:
Step 1 – Create a new farm with matching revision level (or greater)
The system I configured was a basic one server install of MOSS.
You can find your version number by migrating to any SharePoint site’s settings page (i.e. Site Actions, Site Settings). Here is a resource for matching your version level to the installed patch level: http://www.mindsharpblogs.com/penny/articles/481.aspx
Step 2 – Install any Customizations
Next you need to install any customizations such as custom or third party web parts, site templates (i.e. Fabulous 40 Templates)
Step 3 – Restore the Site Collection
Restore the site collection using STSADM’s restore command.
Step 4 – Migrate the site collection’s users
Next you will want to migrate the site collection’s user accounts to your internal accounts. This will ensure that user security, content ownership, and historical changes are maintained.
To migrate the users simply run the STSADM’s migrateuser command for each user.
NOTE: I later experienced an unexpected issue. While the migrateuser command moved user profiles, it did not update the mappings for the site collection administrators. Before you continue make sure you review and update the Site Collection Administrators group with valid internal accounts. If you don’t you will not be able to export the site collection or even run commands like Enumsites. The tools will return an Unknown User error because there is no longer a valid Site Collection Administrator.
Step 5 – Validate the site
Make sure that everything is the way it should be. Test your sites, review the content, and make sure that there are no other templates or pieces missing.
Step 6 – Install Patches
If it is not at the same level as your production server, install all of the Service Packs, Cumulative Updates, and KB patches to match your production environment. Most of those will require running the configuration wizard or pscofig afterward.
Step 7 – Backup the site collection
Run the STSADM’s backup command to export the content.
Step 8 – Restore the site collection to the production server
Restore the site collection using STSADM’s restore command.