After SharePoint 2010 database attach upgrade alerts have the wrong URLs

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()}}

<Insert happy dance here!>

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

13 thoughts on “After SharePoint 2010 database attach upgrade alerts have the wrong URLs”

  1. Thanks Shane!
    Your script rocked – except for one item – I had to blank the siteurl first before I inputed the correct one. minor but could help others!

  2. Thanks for the info. Exactly our issue.
    I think there is a typo in your script to update the single site collection that could lead to some confusion. As you point out in this blog, the siteurl property should be set to the web application url “http://portal” instead of the site collection url “http://portal/sites/new”

  3. Great work! This has updated the property for the siteUrl on each alert object, but for some reason, the alerts are not being picked up.

    When new users subscribe, they get the alert email, but the users who subscribed previous tot he powershell script are not getting the alerts.

    I checked the siteUrl property and saw the new users alert, with the same url as the old users alerts. Any thoughts on how to get these old alerts working?

  4. I ran the first function and saw the old site urls referenced. I then looked in the sql tables for comparison. I then ran the next powershell to update the alert urls and it ran sucessfully however; the site urls did not change in the table. I’m not sure what I am doing wrong. Also it would be great if you could add the output to a text file instead of it going to the UI. I spent a long time trying and ended up using start-transciprt which is really ugly.

  5. Hi Shane,
    I’m also running into a situation as Jen mentioned above. I ran the Update script to update all site collection alerts and not getting any alerts for 2007 migrated alerts. However newly created (in 2010) alerts work fine.

    I then looked into the [ImmedSubscriptions] table and noticed SiteURL was still showing my old Web app url. I tried few other scripts from the Internet and nothing seem to fix my existing alerts. Until I desperately ran Update SQL statement (as per the below blog post) to correct the SiteURL – alerts are now working fine. I know it’s not supported way of fixing so my question is do you have any idea why SiteURL is not updating after running your script?

    Thank you in advanced for any suggestions!

    http://trycatch.be/blogs/tom/archive/2008/05/12/alerts-don-t-work-after-url-change.aspx

  6. Does your website have a contact page? I’m having a tough time locating it but, I’d like to send you an email. I’ve got some suggestions for your blog you might be interested in hearing. Either way, great website and I look forward to seeing it improve over time.

  7. You really make it seem so easy with your presentation but I find this matter to be actually something that I think I would never understand. It seems too complex and extremely broad for me. I am looking forward for your next post, I will try to get the hang of it!

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>