maandag 27 december 2010

Task Assigned Notification bevat verkeerde url (Alternate Access Mappings)

Vandaag weer een bijzonder probleem tegen gekomen bij een klant van me. Was een bijzondere zoektocht, maar wel gaaf dat ik het gevonden heb! Hier het verhaal:

Wat contextinfo:

  1. Deze klant maakt gebruik van Alternate Access Mappings. De url http://sp.***.nl is gemapped naar http://vkc.***.nl.
  2. Wanneer er een nieuwe sitecollection gedeployed word, word dit met Import/Export van SharePoint gedaan.
  3. Er word gebruik gemaakt van een workflow om taken aan te maken.

Het probleem:

In 8 van de 10 sitecollections bevatten alerts van de takenlijst die je krijgt als een item aan jou assigned is overal de url http://sp.***.nl ipv http://vkc.***.nl…. dit muv 2 andere sitecollections die wel goed schenen te werken.

De analyse:

In eerste instantie twijfel je aan je code, dus ga je kijken of de context wel klopt waaronder de taak aangemaakt word. Dit was correct, dus daar kon het niet aan liggen. Helemaal omdat het niet overal fout ging en de workflow overal gelijk is. Daarnaast maakt de workflow alleen de taak aan. Het feit dat deze aan jou assigned is en daar een alert van verstuurd word is standaard SP.

Vervolgens de database maar eens opengeschroefd. In de contentdatabase van de betreffende sitecollection de tabel ImmedSubscription geopend. Daar stond de verradelijke url hard in de tabel. Blijkbaar slaat SP de url van de locatie (site/web) waar de alert is aangemaakt, hard op in de database.

Nieuwe alerts werden goed aangemaakt in deze tabel, enkel oude alerts bevatten de verkeerde waarde. Kan dit niet 100% bevestigen, maar tijdens de import procedure loopt er waarschijnlijk een andere procedure die genoemde tabel update qua waarde. Helaas pakte hij de verkeerde en kan deze dus niet goed overweg met Alternate Access Mappings.

Wanneer in de tabel een url staat die niet bestaat binnen de omgeving, worden er totaal geen alerts meer verstuurd. Dit was een bekend probleem bij migratie van wss2.0 naar wss3.0. Echter, als de url wel bestaat (sp.***.nl) word de mail wel verstuurd, maar bevat hij dus de verkeerde url. Hierdoor lopen andere zaken in de soep die wel afhankelijk zijn van het feit dat de gebruiker op vkc.***.nl zit.

Als eerste werd ik getriggerd door de volgende blogpost. Hier werd uitgelegd welke situatie ervoor zou zorgen dat er geen alerts meer verstuurd werden. Vervolgens een repro op mijn omgeving uitgevoerd en jawel, ik kon de url wijzigen in mijn mails door de SiteUrl in de betreffende tabel te wijzigen. Let wel, de url moet wel bestaan, anders worden er geen mails verstuurd!

De oplossing:

In de Microsoft Sharepoint Administration toolkit zit het UpdateAlert stsadm commando. Met dit commando kan je een site opgeven (siteUrl) en de waarde die je wil veranderen (oldSiteUrl). Vervolgens uitvoeren en voila, de alerts bevatten weer de juiste url.

Geen opmerkingen: