none
Plus d'alertes suite à des mises à jour RRS feed

  • Question

  • Bonjour,

     

    Nous avons effectué des mises à jour sur la plateforme sharepoint (framework...) et depuis les alertes ne fonctionnent plus : Le message de notification de création d'une nouvelle alerte fonctionne, mais par contre les alertes ne sont jamais reçues. J'ai vu quelques sujets similaires sur le net mais pas de solution.

     

    Je travaille sur MOSS 2007, et j'ai effectué les opérations suivantes pour tenter de remettre les alertes en place :

     

    commandes :

     

    net stop sptimerv3 /y

    net start sptimer v3

     

    J'ai stoppé puis démarré le service Windows SharePoint Services Timer

     

    Mais cela ne fonctionne toujours pas.

     

    Merci

    jeudi 7 août 2008 10:42

Toutes les réponses

  •  

    Bonjour,

     

    j'ai le même soucis, sauf qu'il n'y a pas eu de mises à jour (pas que je sache), ça a toujours été comme cela.

    C'est embêtant car cette fonction sera largement utilisée par la suite Tongue Tied

     

    EDIT: nous sommes en sharepoint 2007 12.0.0.4518 (donc pas sp1)

    jeudi 7 août 2008 10:51
  • Dans le cas d'un non fonctionnement total depuis le début, il faut regarder si votre OutCome mail est correctement configuré.
    Il arrive très souvent que le serveur SMTP ne soit pas correctement configuré dans SharePoint, voir que les transferts de mails soient interdit pour le Frontal WEB.

    Pour ce qui est des patches, il faut savoir exactement, le niveau de mise à jour de votre ferme (quelle version de SharePoint, le SP, ...), cf :
     - http://www.asp-php.net/tutorial/asp.net/sharepoint-code-version.php

    Ensuite, il faut regarder dans les LOG et l'Event Viewer si vous ne trouvez pas de message concernant ces tentatives d'envoie.

    Par exemple, vider les log SharePoint et faites une tentative d'ajout d'un utilisateur dans un site avec envoie de mail. Ceci vous permet de voir si les mails partent déjà depuis votre ferme SharePoint ou non.

    Cordialement
    Romelard Fabrice [MVP]

    jeudi 7 août 2008 12:25
  • Merci.

     

    Sachant que je reçois le mail lorsque je crée une alerte cela veut dire que SharePoint est correctement configuré non ?

    De même lorsque j'ajoute une personne sur un site cette dernière recoit l'email, le problème est spécifique aux alertes...

    jeudi 7 août 2008 13:08
  •  

    OK, de ce fait, la cause n'est donc pas liée au routage des Emails, mais bien des alertes elles-même.

    Il faut maintenant savoir exactement ce que vous avez installé. et le niveau de mise à jour.

     

    jeudi 7 août 2008 13:11
  • Nous avons installé le Framework 3.5 sur les frontaux web, et le Service Pack 2 de SQL Server sur les serveurs SQL.

     

    Je suis toujours en version 12.0.0.4518 car une erreur pendant l'installation du SP1 nous a obligé à reporter cette mise à jour.

     

    Merci.

     

    jeudi 7 août 2008 13:31
  • L'installation du SP1 tombée en échec a t-elle été réalisée sur le/les serveurs de production ? Si oui, comment le retour arrière a t-il été fait ?

     

    Si non, y'a t-il eu des mises à jour au niveau de l'OS ?

    jeudi 7 août 2008 13:56
    Modérateur
  • Ca commence pas très bien dans ce cadre.

    Il est possible que vous vous retrouviez dans une situation avec un ecart de version entre les différents composants de votre ferme.

    Je vous invite à vérifier ceci sur chaque serveur de votre ferme (registry de chaque serveur et SQL) :

     - http://www.asp-php.net/tutorial/asp.net/sharepoint-code-version.php

     

    Romelard Fabrice [MVP]

    jeudi 7 août 2008 14:12
  • Bonjour,

     

    de mon coté j'ai fais le test avec l'utilisateur, et le message de bienvenue arrive bel et bien dans la boite mail de l'user.

     

    Du coté des logs, eventwvr, néant.

    D'ou peut venir ce problème ??

    vendredi 8 août 2008 08:29
  • En résumé, tout ce qui s'appui sur un envoi de mail direct fonctionne (inscription pour l'alerte, message de bienvenue, etc.)

     

    En revanche, l'envoi de mail planifié semble poser problème, ce qui me ramène au timer.

     

    J'ai vu quelques problèmes survenant avec le timer, dans les cas suivants :

     

    • modification manuelle de la date/heure du serveur

     

    Essayez de réajuster la fréquence de traitement des alertes avec la commande stsadm -o setproperty Job-immediate-alerts (http://technet.microsoft.com/en-us/library/cc262432.aspx)

     

    Si ceclà ne fonctionne pas, essayez également de resynchroniser l'heure de votre serveur avec celle de votre domaine (en général gérée par le controleur de domaine) : net time \\<machine_dc> /set /yes... mais sans grande conviction.

    vendredi 8 août 2008 08:45
    Modérateur
  • Oui voilà, et même les envois direct lors d'un changement d'élément dans une liste ne fonctionnent pas (et ceux programmé par jour / semaine non plus).

     

     

    Merci pour ces infos

     

    j'ai tester cette commande :

     

    To view the setting for the job-immediate-alerts property, use the following syntax:

    stsadm -o getproperty -pn jobs-immediate-alerts

     

    -> Object reference not set to an instance of an object.

     

    Je n'ose pas trop chipoter avec le stsadm pour des raisons de "permissions" Stick out tongue

    vendredi 8 août 2008 09:03
  • Il y a quand même quelque chose que je ne comprend pas :

     

    Specifies the frequency schedule to check alerts that are set to be sent immediately. The value should be a properly formatted Windows SharePoint Services Timer service (SPTimer) in the form of any one of the following schedules:

    •"Every 5 minutes between 0 and 59"

    •"Hourly between 0 and 59"

    •"Daily at 15:00:00"

    •"Weekly between Fri 22:00:00 and Sun 06:00:00"

     

     

    Je m'abonne à une liste et je demande d'être alerté immédiatement si un item change par exemple, donc je dois recevoir l'email directement.

    Ici on peut par exemple mettre le timer sur weekly, donc si je fais ça, je vais devoir attendre 1 semaine pour recevoir un email que j'attendais de recevoir dès que mon document à été modifié ?

    vendredi 8 août 2008 12:42
  • Oui, même si l'idée est plutôt de faire l'inverse. Cette commande ne modifie pas la périodicité des abonnements, mais la fréquence avec laquelle le timer vérifie ce qu'il y a à envoyer. J'aurais tendance à utiliser quelque chose du genre "Every 1 minutes between 0 and 59" de façon à forcer le timer... quitte à remettre une valeur raisonnable par la suite.

     

    vendredi 8 août 2008 12:46
    Modérateur
  •  

    stsadm -o setproperty -pn job-immediate-alerts -pv "Every 1 minutes between 0 and 59"

     

    c'est exactement ce que j'avais préparé Smile

     

    Ce que j'ai du mal à comprendre c'est pourquoi passer par un timer quand on doit envoyer des alerte immédiatement.

    Je pense que chez Microsoft ils ne voulaient pas sortir du timer pour cette fonctionnalité, mais j'avoue que là comme ça, c'était déconcertant pour moi.

     

    Je vais tester celà et voir ce que ça donne, de toute façon ça ne risque pas de faire des dégats sur un server en prod de genre de commande !

     

    Qu'entendez-vous par valeur raisonnable par la suite ? Est ce que ce timer consomme beaucoup de ressources ?

    vendredi 8 août 2008 12:52
  • Je n'ai pas d'indicateur sur le coût que représente le timer... d'autant qu'il y a pas mal de jobs qui y sont liés. Généralement, les alertes partent au bout d'une durée allant de 0 à 10/15 mn, c'est ce que j'ai pu remarquer. Une fois que celà fonctionnera, ce sera probablement une bonne chose de remettre une fréquence proche des 10 mn.

     

    Avant de lancer cette commande en production, je ne peux que vous conseiller de la tester sur un environnement de test... on ne sait jamais. Personnellement j'ai utilisé une commande similaire pour palier au problème du DelayActivity dans les workflows.

     

    vendredi 8 août 2008 12:56
    Modérateur
  • D'accord, personnelement je trouve que ceux qui veulent être informé directement d'un changement sur la liste doivent avoir l'info rapidement (5 min me semble raisonnable pour le timer job).

     

    L'utilisateur quand il s'abonne, l'intitulé de l'option send me an alert immediatly serait bien trompeuse si il rate le coche du timer et doit attendre 15 min par exemple.

     

    Malheureusement ici ils n'ont pas d'environnement de test, j'ai bien mes vpc avec moi mais je n'ai qu'un go de ram ici, difficile à tester Stick out tongue

     

    De plus sur ma vpc je n'avais pas configuré les mails et rien ne me dis que j'aurai le même problème (je suis en sp1 en plus).

     

    Néanmoins j'hésite à lancer cette commande maintenant

     

    vendredi 8 août 2008 13:04
  • A priori, pas de soucis avec cette commande, mais mieux vaut toujours tester au préalable, même sur une VPC.

     

    Vous ne risquez rien sur les alertes (qui ne fonctionnent déjà plus), mais même si un redémarrage de IIS est très peu probable, je ne m'y risquerai pas à moins d'avoir testé la commande.

     

    vendredi 8 août 2008 13:07
    Modérateur
  • Je crois que c'est le plus sûre en effet, je pense que ce soir je testerai cela sur ma vpc ..

     

    Un reset d'iis, mm ici interdit ! Peut rien faire faut tout le temps demander, et le temps de réponse avec eux la bas est... très long (j'ai rajouté l'icone des pdf pour les articles de contenu, et je n'ai toujours pas l'icone qui apparait, il faut faire un reset et je ne sais pas tout les combien de temps ils reboot leur serveurs).

     

    Là j'ai le SharePoint Warmup Job en solution .wsp que j'aimerai déployer sur le server pour ne pas devoir attendre 2 min chaque matin... mais même ça il faut demander alors que c'est juste 2 lignes avec stsadm.

     

    Vous voyez les complications quoi Smile

     

    vendredi 8 août 2008 13:19
  • Désolé, c'était un abus de langage. Je voulais simplement dire qu'au pire (et j'en doute), la commande aurait pour conséquence de recycler le ou les pools d'application... mais très honnêtement je ne pense pas.

     

    vendredi 8 août 2008 13:22
    Modérateur
  • Ha d'accord en gros elle n'a pas l'air très dangereuse cette commande.

     

    vendredi 8 août 2008 13:26
  •  

    Encore un abus de ma part (même si on ne peut pas qualifier une commande SharePoint de dangeureuse ).

     

    Le "pire" valait pour l'interruption de service... mais sans l'avoir testé, c'est délicat de se prononcer dessus... vous comprenez bien .

     

    Bref, comme toute commande, testez là sur un autre environnement avant...

    vendredi 8 août 2008 13:30
    Modérateur
  •  

    On pourrait Stick out tongue (deletecontentdb c'est sympas aussi)

     

    Mais oui je vais la tester avant de toute façon Smile

     

    Merci pour toutes ces informations Smile

     

     

    vendredi 8 août 2008 13:36
  • Voilà alors 2 choses :

     

    sur le server intranet, ils se sont décidé à faire qqch, eux on réussis à faire refonctionner les alertes avec ce script :

     

    Code Snippet

    restarttimer.bat:

    NET STOP "Windows SharePoint Services Timer"
    NET START "Windows SharePoint Services Timer"
    NET STOP "Windows SharePoint Services Administration"
    NET START "Windows SharePoint Services Administration"
    STSADM -o ExecAdmSvcJobs

     

     

    Ce matin ma boite mail était pleine d'alerte mail hebdomadaire depuis le 27 juillet.

     

    De mon coté j'ai testé la commande :

     

    Code Snippet

    stsadm -o setproperty -pn job-immediate-alerts -pv "Every 1 minutes between 0 and 59"

     

     

    sur mon environnement de test, et ça a eu pour effet de faire fonctionner les alertes Smile

     

    (dans les 2 cas, sur le server de prod la commande stsadm -o getproperty -pn job-immediate-alerts répondais : object reference not set to an instance of an object, et sur mon environnement de test : <Property Exists="No" /> (je suis en sp1 sur l'env de test)).

     

    Apparement il faut réinitialiser ce paramètre à chaque nouvelle installation sharepoint (en tout cas j'y veillerai à l'avenir).

     

     

    mardi 12 août 2008 09:33
  • Merci à tous pour vos réponses, malheureusement le problème reste entier.

     

    Je suis depuis passé au SP1 (12.0.0.6219) mais les alertes ne fonctionnent toujours pas. J'ai tenté toutes les manipulations proposées dans les différents posts, sans succès...

     

    Merci d'avance.

    jeudi 14 août 2008 07:36
  •  

    Bonjour,

     

    que répond votre server avec cette commande : stsadm -o getproperty -pn jobs-immediate-alerts

     ?

    jeudi 14 août 2008 08:13
  • Bonjour,

     

    Cela m'affiche <Property Exists="No"> si je la fais comme cela.

    En revanche, si je précise -url https://monserveur alors la j'ai "Every 5 minutes between 0 and 59"

     

    Dois la définir aussi sans url ?

     

    (petite précision, il s'agit de job-immediate-alerts et non pas jobs, qui ne marche pas)

    jeudi 14 août 2008 09:00
  • Effectivement c'est confusant, cependant j'essaierai quand même de définir le timer comme je l'ai fais sur mon environnement de test (voir posts précédant).

     

    Dans mon cas ça à fonctionné, ne préciser pas l'url pour le setproperty et voyez ce que cela donne.

     

    ayant testé cela sur un environnement de test, et vu que mon environnement tourne toujours, je pense que vous ne risquez rien (le risque 0 n'existe pas bien sur Wink)

    jeudi 14 août 2008 10:31
  • Ce script est connu pour les problèmes avec le delay activity, la version complete est même :

     

     

    Code Snippet

    @ECHO ON
    :: Stop IIS Admin Service
    net stop IISAdmin /Y

    :: Above should also stop the following
    :: HTTPFilter
    :: Pop3Svc
    :: SMTPSVC
    :: W3SVC

    :: Now stop SharePoint's Timer Service
    net stop SPTimerV3 /Y

    :: Now restart things in reverse sequence from how we turned them off
    net start SPTimerV3

    net start W3SVC

    net start HTTPFilter

    ::net start Pop3Svc

    net start SMTPSVC

    :: now start the 'parent' of the above services
    net start IISAdmin

    ::PAUSE

     

     


    Il correspond à un redémarrage des services NT dans le bon ordre pour que le timer ne coince pas sur les envois de mail (ou taches) planifiés comme les sorties de delay ou les alertes.

     

    PS, le dernier patch d'infrastructure est censé corriger ce point, mais nécessite l'installation du SP1.

    Il faudra vraiment prévoir la mise à jour de votre ferme.

     

    Cordialement

    jeudi 14 août 2008 11:46
  • Merci une fois de plus, j'ai effectué ces opérations mais toujours sans succès.

    En revanche je suis à présent en SP1 (v. 12.0.0.6219), mais je n'ai toujours pas d'alertes Sad

     

    Merci pour votre aide.

    lundi 18 août 2008 09:09
  • Re-Bonjour,

     

    Je commence à désespérer, j'ai tenté toutes les commandes proposées dans ce post et bien d autres, j ai redémarré le serveur, les services un à un et rien n'y fait...

     

    J'ai juste pu constater ces quelques lignes dans mes logs SharePoint qui peut etre sont a l origine du problème :

     

    OWSTIMER.EXE 8u3j High Registry key value {SearchThrottled} was not found under registry hive {Software\Microsoft\Office Server\12.0}. Assuming search sku is not throttled. 

     

    J'ai essayé de voir si je trouvais des infos sur google, je trouve bcp de personnes avec ce meme message mais aucune solution. N'importe quelle idée est plus que bienvenue.

     

    Merci.

     

    lundi 25 août 2008 07:54