none
WPRESOURCES : Confusion entre inetpub et common files RRS feed

  • Question

  • Bonjour

    je tente d'installer le TSportalWebPart en suivant la doc Customizing Remote Desktop Web Access by Using Windows SharePoint Services Step-by-Step Guide (Sauf que la doc est simpliste, dédiée à un environnement monoserveur, et qu'il faut chercher beaucoup pour travailler avec 1 ferme SHP + 1 autre ferme RDS.)  En fait le rôle Services de bureau distant doit être créé à la fois sur la ferme hôte des remote app mais aussi sur la ferme SHP, pour que le TSportalWebPart soit disponible pour être ajouté dans la gallerie.

    J'ai créé (avec les droits) les dossiers "%SystemDrive%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources\TSPortalWebPart\6.1.0.0__31bf3856ad364e35\images” et ...\rdp

    Au moment ou j'ajoute mon webpart dans une page de wp, Sharepoint me dit qu'il ne trouve pas le dossier inetpub\wwroot\virtual directories\80\{mon site secondaire}\_wpresources 

    Pourquoi va-t-il chercher _wpresources (avec tiret bas) dans inetpub plutôt que wpresources (sans _ ) dans program files ?

    Pour avancer, j'ai copié l'un dans l'autre ; du coup le webpart est accepté, mais se comporte très mal :

    • il ne récupère pas les icones des remote apps
    • si je fait appel au webpart dans une autre page sur un autre site, il faut que je duplique encore le _wpresources

    Merci de votre aide.

    mercredi 30 juin 2010 10:14

Réponses

  • J'ai tenté de déplacer l'appel du weppart, mais le lieu de stokage est mémorisé. Voici pour les confrères comment j'ai réglé le problème.

    Le TSwebPortal n'est pas un wepbpart de classe microsoft.sharepoint mais de classe microsoft.publishing. Il est installé avec le service de rôle "acces bureau distant par le web". J'ai fait sur mes deux serveurs frontaux les opérations suivantes :

    • suppression des pages appelant le wp
    • suppression du wp dans la gallerie de composant
    • suppression du service de rôle, qui supprime le rôle lui-même ; reboot
    • reinstall du rôle et du service
    • reset IIS pour que le composant soit visible dans MOSS

    ensuite reconstruction propre

    • ajout dans la galerie de composant
    • ajout du wp dans une page au niveau racine de l'appli web shp (pour éviter le bug précédent)

    L'appel du WP marche bien. :-)

    A part ça l'utilisateur doit cocher à chaque fois "j'utilise un ordinateur privé" pour que le SSO fonctionne. Impossible de le plomber ?

    • Marqué comme réponse Alex Petrescu lundi 5 juillet 2010 08:54
    vendredi 2 juillet 2010 05:40

Toutes les réponses

  • Bonjour,

    c'est un virtual directory, comme _layouts qui correspond a layouts dans program files.

    Ile ne faut pas copier l'un dans l'autre mais faire un virtual directory dans IIS qui pointe sur celui dans program files.

    aussi verifier les droits des utilisateurs sur ce repertoire.


    Xavier VANNESTE
    www.xvanneste.com
    media.xvanneste.com
    blog.xvanneste.com
    mercredi 30 juin 2010 11:00
    Auteur de réponse
  • Merci,

    En fait il me rajoute un niveau (le nom du site secondaire) alors que sans cela IIS pourrait trouver _wpresources qui est bien définie pour la racine.

    Mais maintenant mon pb reste mémorisé quelque part. J'ai eu beau faire du ménage, si je veux réutiliser mon webpart, il me demande toujours la même adresse = ...80\{mon site secondaire}\_wpresources .

    D'où à où dois-je faire ma redirection ? Créer un répertoire bidon "mon site secondaire" puis dedans le virtuel  _wpresources ?

    (je précise mon arborescence = http://intranet/{mon site secondaire} )

    mercredi 30 juin 2010 15:59
  • Je connais mal cette webpart mais n'y a t il pas un parametre dans les parametre de la webpart qui permettrais de changer la connection
    Xavier VANNESTE
    www.xvanneste.com
    media.xvanneste.com
    blog.xvanneste.com
    mercredi 30 juin 2010 16:05
    Auteur de réponse
  • J'ai tenté de déplacer l'appel du weppart, mais le lieu de stokage est mémorisé. Voici pour les confrères comment j'ai réglé le problème.

    Le TSwebPortal n'est pas un wepbpart de classe microsoft.sharepoint mais de classe microsoft.publishing. Il est installé avec le service de rôle "acces bureau distant par le web". J'ai fait sur mes deux serveurs frontaux les opérations suivantes :

    • suppression des pages appelant le wp
    • suppression du wp dans la gallerie de composant
    • suppression du service de rôle, qui supprime le rôle lui-même ; reboot
    • reinstall du rôle et du service
    • reset IIS pour que le composant soit visible dans MOSS

    ensuite reconstruction propre

    • ajout dans la galerie de composant
    • ajout du wp dans une page au niveau racine de l'appli web shp (pour éviter le bug précédent)

    L'appel du WP marche bien. :-)

    A part ça l'utilisateur doit cocher à chaque fois "j'utilise un ordinateur privé" pour que le SSO fonctionne. Impossible de le plomber ?

    • Marqué comme réponse Alex Petrescu lundi 5 juillet 2010 08:54
    vendredi 2 juillet 2010 05:40