Search results matching tag 'upgrade'

SharePoint 2013 is coming, SharePoint 2013 is coming

Anonymous — Tue, 02 Oct 2012 12:57:46 GMT

Thankfully, unlike the night of Paul Revere's fateful ride we are happy to see it coming. Side note: If you are bored go read this article talking about Israel Bissell who did the hard work. He managed to ride 345 miles to Paul's 12. Unfortunately Bissell doesn't rhyme as well as Revere. J Ok, enough history back to SharePoint.

SharePoint 2013 is exciting with lots of new features. Two of the biggest will be more social capabilities and the App store. The inspiration for social feature are pretty clear, it is like a hybrid of Twitter and Facebook. That's a really good thing as we move closer to the social enterprise. The App store just makes sense. Everyone these days has more Apps than they can even imagine at their fingertips on their smart phones, it was only logical that other software would start having the same capabilities. These two features are just scratching the surface of SharePoint 2013. Fortunately, if you are interested, Microsoft has some great reading on what is new and the Rackspace team has provided 9 free videos showing off some of the 2013 coolness. This article isn't about what is new.

The thing I want to focus on, the information that is hardest to find, is what you can be doing today to get ready for when the final version of SharePoint 2013 is released. The easy answer is nothing. If you are actively caring for and feeding SharePoint then you have nothing to worry about. On the other hand, if you haven't been showing your SharePoint farm all the love and attention it deserves don't feel too bad, about 95% of farms are in the same situation. If you are a little behind, let's talk a little about your "fall cleaning" plans.

Patching

Where are you with patching your current SharePoint 2010 farm? You don't know do you? That isn't a good sign. Luckily Todd has a great post that helps you find your build number and then tells you what that number means. Now, when you look at Todd's list you don't necessarily need to be on the latest and greatest; technically as long as you are at RTM then upgrading to 2013 is supported. Let's be honest though, you shouldn't be running RTM. You should be at service pack 1(SP1) at a minimum. There are 100's of fixes between RTM and SP1 so if you are not there then get a plan together to get there. What about all of those cumulative updates (CU) after SP1? Good question. As a rule of thumb you shouldn't apply a CU unless you have a specific problem and you can point to the CU that fixes it. CUs are not tested like service packs and can introduce a lot of risk. With that in mind be sure to read Todd's note on each Cumulative Update carefully to get an idea of what features they may fix or add. Another important point to remember, there is no way to uninstall a SharePoint CU or SP once you start installing it, so practice on a test farm first and then plan for the worst.

Purging

When was the last time you deleted old content out of SharePoint? No, not your field guide to the battle of Lexington and Concord, but all of those SharePoint sites that nobody uses. There have been studies that show up to 50% of collaboration sites that get created are never used. Even if you are 50% better than the average company, did you delete the 25% that aren't in use? Probably not. This is a great way to get ready for your upgrade. Everything about less content is a win when it comes to doing an upgrade. Nothing is worse than troubleshooting upgrade errors for content that you just end up deleting.

Preparing

Since SharePoint 2013 isn't RTM yet hardware specifics are still a little up in the air, but it is still obvious there will be changes. For example, are you using the Office Web Applications in SharePoint 2010? In 2010 Office Web Apps are required to be installed on a SharePoint server. In 2013 it is required that they not be installed on a SharePoint server. With that one change you have already added at least one server to your farm. What about the operating system and SQL? Windows Server 2008 (not R2) and SQL 2005 or 2008 were supported. Not with SharePoint 2013. Digging into the hardware and software requirements document provided by Microsoft will give you the information you will need to start planning you infrastructure to support SharePoint.

There is a lot more you could do to get prepared, but let's not get carried away. Your server room has smoke detectors, so one lantern by land or two by water might be overkill. If you can get through patching, purging, and preparing then you should be in good shape.

Shane Young – Rackspace Hosting

Video Best Practices & Lessons Learned for SharePoint 2010 Upgrade With Joel Oleson

Anonymous — Fri, 18 Nov 2011 07:02:55 GMT

On Wednesday the 16th November i had the great pleasure of hosting a webinar with Joel Oleson talking about lessons learnt when upgrading to SharePoint 2010. So i am very pleased that the recording of the webinar is now available and can be found below. Some great advice can be found in the webinar. Back in [...]

10 technical considerations before upgrading to SharePoint 2010

Anonymous — Sun, 11 Sep 2011 09:58:09 GMT

May 12th 2011 marked the first anniversary of the release of SharePoint 2010 and we are still doing a lot of work around the upgrade/migration space so I thought I would put together a couple of blog posts with considerations before embarking upon the journey. So in this post I will look at the technical considerations [...]

After SharePoint 2010 database attach upgrade alerts have the wrong URLs

Anonymous — Mon, 22 Aug 2011 18:47:21 GMT

Database attach upgrades seem to be the norm these days for customers upgrade from SharePoint 2007 to SharePoint 2010. I am assuming the reason for this is because they are very flexible and generally work pretty well. One of the flexible things about these type of upgrades is you can change your web application URL. Some customers are going from short URL to fully qualified (FQDN) like http://portal to http://portal.company.com. And some of our customers are making complete changes going from http://sharepoint.company.com to http://intranet.company.com. The nice thing about making these types of changes is for the most part a content database has no concept of the web application URL. If you go hunting through the database (which you should never do) you will see everything is relative. The site collections know their urls as / or /sites/sitecollection. That way changing the URL doesn't matter.

But then there are alerts. Alerts are hard coded to the web application URL that was used to create the alert. This is why if you have multiple URLs for you SharePoint site your alerts may be inconsistent. If your portal is setup so you can access it as http://portal or http://portal.contoso.com then whichever of those URLs you are browsing the site with when you click create alert will be the URL SharePoint sends out in the alerts. Kind of annoying for some people but it is what it is. The real problem comes if you switch URLs.

If you change your web applications URL (maybe during an upgrade but not necessarily) everything will continue to work great except for existing alerts. When you have an alert sent to you it will still have that original URL you used to create the alert even if that is no longer a valid URL. Boo!

Now if you do a Bing search of the internet you will find lots of people point to this TechNet resource http://technet.microsoft.com/en-us/library/cc508847.aspx which will prompt you to create a Windows PowerShell script to fix alerts. One small problem. The script only works to update the URL of alerts for the root site collection. In their script they confuse the web application URL and the site collection URL. To be fair I don't blame them. When you look at the configuration objects you will see it wants siteUrl and we have been taught that usually inside of SharePoint site = site collection. Unfortunately in this case siteUrl actual means web application URL.

In the beginning when we used their script to update http://portal/sites/old to http://portal/sites/new our alerts had the link as http://portal/sites/new/sites/new/list which has /sites/new twice.

So then I decided to look at things on my own. I created a new alert through the GUI and then used the following script:

Get-SPweb -site http://portal/sites/new -limit all | ForEach-Object {$_.alerts|foreach-object{write-host $_.user $_.properties["siteUrl"] $_.properties["dispformurl"]}}

This gave me a list of all the alerts for the site collection http://portal/sites/new and I saw the value for siteUrl was http://portal. Hooray!

So then I used this script to update just the alerts in that site collection:

Get-SPweb -site http://portal/sites/new -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://portal/sites/new";$_.update()}}

Success! But seemed silly to just fix the one site collection so then I wrote a better script that updates the entire web application:

get-spsite -limit all -WebApplication http://portal | get-spweb -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://portal";$_.update()}}

Now if you compare my script to theirs you will notice I don't bother with mobileUrl because no one I know uses it. Also, they rewrite some other properties. If you want to do the same you can piece together the two scripts to do it but for right now for my customers this is working.

Hope this helps

Shane

SharePoint Consulting and now SharePoint Training

SharePoint How to upgrade with read-only databases

Anonymous — Mon, 18 Jul 2011 06:15:48 GMT

Walkthrough of process that completes a database attach upgrade with read-only databases to SharePoint 2010. Video: How to upgrade with read-only databases Technorati Tags: Sharepoint 2010, Upgrade

Upgrading User Profile Choice Fields to SharePoint 2010

Anonymous — Wed, 20 Apr 2011 03:01:37 GMT

I’m working on an upgrade (database attach) for a client of mine and I ran into something somewhat unexpected with some User Profile properties – properties that used a choice field in 2007 (fields that allowed the administrator to define a list of values that the user could pick from) were migrated to Managed Term [...]

SharePoint 2010 database attach upgrade with managed paths

Anonymous — Mon, 25 Oct 2010 15:00:52 GMT

This week I found a new to me issue with doing a database attach upgrade from 2007 to 2010. It seems if your 2007 content database has additional wildcard managed paths (anything other than /sites) that when you upgrade that database to SharePoint 2010 that you will end up with a bunch of explicit managed paths in SharePoint 2010. Kind of break downs like this:

2007 Wildcard managed paths:

/sites
/departments
/projects

2007 site collections in the content database:

/
/sites/teamsite
/departments/hr
/departments/accounting
/projects/CowMachine
/projects/CowNinja

When you create a new 2010 web application and attach the content database you will get the following managed paths:

/sites - wildcard
/departments/hr - explicit
/departments/accounting - explicit
/projects/CowMachine - explicit
/projects/CowNinja - explicit

And of course all of your site collections will be available.

As you can quickly tell this is way less than ideal. For one when you try to create a new site collection for the Cow Black Ops project you will not be able to create it at /projects/BlackOpsCows because there is no longer a managed path for /projects. Boo! So how do you fix it? About time you asked.

Create managed paths before attaching 2007 content databases

The fix here is quite simple. Know your managed paths you need before you do your upgrade. Then right after you create the 2010 web application and before you do the mount-spcontentdatabase you need to go into Central Admin > Web Application management, click your web application and then from the ribbon select managed paths. Now create your wildcard manage paths. In this example you create /departments and /projects. Now return to your regularly scheduled program and do your 2007 content database upgrade.

If you already find yourself with this issue the fix is as simple as you are assuming. Go into central admin > manage content databases and remove your upgraded databases. Once they are detached go delete all of the explicit managed paths for your database. Then create the wild card paths you want. Now reattach your content database. All better. J

Hope this helps

Shane

SharePoint Consulting

Move Single Server Install to New Server Then split out DB

nosajld — Thu, 07 Oct 2010 19:26:31 GMT

Greetings -

We are in the process of moving our single install (search, SQL and Front End) on one server to a newer upgraded server. After the move and testing we are going to then split the DB out to a Standalone SQL server.

1. What is the best way to move to the new server?

2. What is the best way to split out the DB's?

I have read several technet articles on each of these subjects but I'm looking more for best practices / real world folks who have done this before.

Any information, links, comments welcome!

Thank you!

Jason Dodson

Re: Upgrading from WSS 3 to Foundation Services 2010

ferringer — Thu, 26 Aug 2010 19:01:17 GMT

You're going to want to undertake what is referred to as the "database attach upgrade" process. Basically what you'll do is:

Confirm that your WSS v3 farm is patched at least to Service Pack 2 (SP2). I'd recommend that you also apply the latest cumulative update to get to the latest and greatest version of SharePoint. You must be on at least SP2 to be able to upgrade your content to the new SharePoint Server 2010 farm
Make backups of your WSS v3 content databases
Build your SharePoint 2010 farm
If you had any custom or third party code or customizations in your WSS environment, deploy them to your 2010 far and test them thoroughly to make sure they're compatible.
Take those backups and restore them into the SQL Server instance of your SharePoint 2010 farm
Attach those content databases to a Web Application in the SharePoint 2010 farm
Open your sites in the new farm and make sure that they are functioning properly
Perform visual upgrades on those sites as desired to apply SharePoint 2010's user interface

For general information on upgrading from Microsoft, here's the overall TechNet article: http://technet.microsoft.com/en-us/library/cc303420.aspx

For information specifically on the database attach upgrade process, see http://technet.microsoft.com/en-us/library/cc303436.aspx

There's also a book about upgrading to 2010 coming this December from Joel Oleson: http://www.amazon.com/SharePoint-2010-Practices-Upgrading-Migrating/dp/1449390439/ref=sr_1_3?ie=UTF8&s=books&qid=1282316688&sr=8-3

John

Unable to access Lists and Document Libraries From SPD 2010 in upgraded SPF 2010 site

steam23 — Thu, 05 Aug 2010 01:45:49 GMT

I took the plunge with my company's WSS 3 site and upgraded to SPF 2010. I used the database attach method. So we're now running SPF 2010 with a SQL 2008 R2 server. The upgrade seemed to go fine and I'm able to access the whole site. There've been a few bumps on the road, but mostly fairly smooth.

Now, however, there are a couple things I can't seem to do. I can open the top level site with SPD 2010 but there aren't any items in Site Objects--> Lists or Site Objects -->Document Libraries. Also, if I click the Lists or Data Sources buttons, it will show "no items available." The Web Parts button only shows basic web parts and has no items for document libraries or lists. If I navigate to Site Objects-->All Folders, I can see my whole site including lists. Also, if I edit a customized page with data view web parts, I can see the data source details in the detail panel, but I can't add any new ones.

I'm not sure if it's related, but I've also noticed that the Site Actions button on the main site doesn't contain items for "Edit in Sharepoint Designer" or "Site Workflows" or "Visual Upgrade."

Also, all the options I mentioned above site objects, and site actions both work fine in sub sites.

I thought perhaps there was a problem when I updated the content database, so I removed all the missing site features from the Server Dependencies Health monitor report and ran a upgrade-spcontentdatabase to resume the upgrade, in case it hadn't completed. However, it told me that the database didn't require updating. To confirm, I ran stsadm -o localupgradestatus. It showed all the databases as being properly updated.

I'd really appreciate a direction to explore here. This is obvoiusly a deal-breaker. I have a full backup of my old configuration, but I'd hate to have to toss out the work I've put in so far!