Fixing programmatic alert URLs

Question

Environment: SP2010 Enterprise, SQL2008R2, VS2012, full server access

A while ago I created a massive amount of alerts using a c# console app I made in VS. The app ran on the server using SP administrative credentials. Lo and behold all the alerts now have the server name in their links, therefore the alert links are broken for all external users. I have come to learn this is the result of A) Having the server name as the default zone URL, and B) Creating the alerts through said default zone.

I found a possible solution here using the AlertFixup PS cmdlet, but the situation it was designed for is slightly different. It's meant for sites whose URLs have changed, whereas in my case it has not, I just want to change it to a different zone. Additionally I ran a -whatif on it and it ultimately reported 49 alerts it could fix even though it iterated through several thousand of them (after some examination I discovered that only 49 of them could fit in the command prompt window at any given time) so my other question here is can that cmdlet handle the volume of alerts that I need to fix?

Sum-up: Is the AlertFixup cmdlet applicable to this situation (just changing the URL to whatever I want)? If necessary to make the AlertFixup work, is it safe to just change the default zone of the web app to the external URL and then run AlertFixup? Can it handle a huge volume of alerts? Is there another way to easily modify all the existing alerts to fix the URLs (perhaps with an SPAlert property)?

Answer 1

The solution (direct link here: http://gallery.technet.microsoft.com/ScriptCenter/877d2abd-fce9-4545-b223-7637936dd888/) looks pretty good.

it would be a benefit to you to read through the script and understand what it is doing.

If you wanted to update the url of the first alert in the web ~http://notreallymycompany.com/butreally/myweb to ~http://ShinyNewUrl.bliss you could do it like this:

(get-spweb http://notreallymycompany.com/butreally/myweb).Alerts[0] | foreach-object 
{
       $_.Properties["siteUrl"] = "http://ShinyNewUrl.bliss"; 
       $_.update()
}

The rest of the script is used to do the iteration and manage errors and apply the update.

If I were in your shoes, I would iterate through all of the alerts in all of the sites and get the web url, the username, the listname, and the alert id and save that list to a spreadsheet for an inventory of what your alerts are really set to. then I would know for sure if 49 is the right number of corrections that should be made.

Also, note that the script was written for SP 2007 and there are easier ways of doing things in SP 2010 even though what is there should work fine for you.

Answer 2

Okay for those who are curious here's what I ended up doing:

The script @ghangas and I were discussing was meant for fixing alerts that were created before a site URL changed. In my case there was no URL change for the site, I just needed to alter the URLs of the existing alerts. Because of this, the script did not fix things the way I needed, because it was built to only work within one zone (for a reason), not giving free access to change the URL to whatever you want.

ghangas was right about the siteUrl property being the only thing that is actually changed. With that knowledge I simply built a c# app (my preferred language over PowerShell, but it works the same) that changes that property for every alert in the site, since it is exclusively public-facing anyways. It took a little over an hour for it to modify and update all 31,000 alerts, but in the end it worked perfectly. Here's the operational part of the code:

public static void FixAlertUrl()
{
    using (SPSite oSite = new SPSite("http://server/site"))
    {
        using (SPWeb oWeb = oSite.OpenWeb(oSite.RootWeb.ID))
        {
            SPAlertCollection oAlertCol = oWeb.Alerts;
            int counter = 0;
            foreach (SPAlert vAlert in oAlertCol)
            {
                vAlert.Properties["siteUrl"] = "http://newurl.domain.com";
                vAlert.Update();
                counter++;
                Console.WriteLine(counter);
            }
        }
    }
}

Note that the correct URL for alerts in this case is simply the public DNS name of the WFE, not the whole path to the site. SharePoint automatically tacks on the /collection/site/subsite in the alert template (important detail for those looking to customize the templates themselves).

Hope that helps someone!