locked
L'appel échoue depuis Internet RRS feed

  • Question

  • Bonjour à tous,

    J'ai une question concernant Lync. Je l'ai déployé sur un serveur à l'extérieur de mon organisation de façon standard et sans edge ni proxy. J'arrive parfaitement à me connecter via le client Lync au serveur et à discuter avec les autres membres de mon organisation. 

    Sur mon réseau d'entreprise, les appels téléphoniques fonctionnent bien aucun soucis de ce côté là. Même sur mon réseau d'entreprise j'attaque le serveur Lync à distance.

    Par contre, depuis chez moi lorsque je veut passer un coup de téléphone à un autre utilisateur j'ai le message d'erreur "L'appel à échoué due à des problèmes réseaux".

    C'est étrange car même depuis chez moi je suis capable de discuter, partager des documents sans problème. J'ai vu qu'il fallait un serveur Edge pour l'accès externe mais je ne sais pas si cela s'applique à mon cas. Je trouve étrange que la messagerie fonctionne alors que les appels non.

    Quelqu'un à t-il une piste ?

    Merci

     

     


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    jeudi 16 juin 2011 10:14

Réponses

  • Bonsoir,

    Je comprends mieux votre problème. Je pensais que vous vouliez utiliser les fonctions d'appels vers du PSTN en passant par un serveur de médiation collocalisé ou non. Dans ce cas là il aurait fallu la version Enterprise de Lync...

    Vous utilisez une version standard, dans laquelle vous retrouvez toutes les fonctions du déploiement enterprise sauf le "Voice Enterprise", et j'étais parti dessus...

     

    Revenons à votre problème, vous me dites que vous avez déployer votre serveur à l'extérieur de votre LAN, or lorsque vous appelé dans votre LAN d'un PC à l'autre tout fonctionne...

    Le problème? LE NAT j'en suis quasi sur! Essayez depuis chez vous de vous connectez à deux client Lync sur le même sous réseau.

    Je pense que le déploiement va marcher si vos clients sont dans le même subnet, c'est pourquoi il fonctionne dans votre LAN entre deux PC.

    Je pense que vous n'échapperez pas au serveur Edge, c'est son rôle, si vous voulez permettre l'accès aux utilisateurs externes à Lync.

    Voici un lien qui vous sera utile (déployer un serveur Edge):

    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=85c62b26-e509-435e-811f-71c8c89dca83

    Tenez moi au courant si le problème est du au NAT, je peux me tromper, mais bon...

    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    lundi 20 juin 2011 21:16
  • Bonjour,

     

    Le serveur Edge est requis pour permettre l'accès aux utilisateurs externes.

    Effectivement votre serveur Edge va agir comme un "routeur NAT".

    Sur le fait, si il est possible de régler ce problème sans passer par Edge, à priori non.

     

    Ceci va vous aidez à mieux comprendre les rôles de chaque composants (Edge, Reverse Proxy, role director):

    http://technet.microsoft.com/en-us/library/gg425779.aspx

     

    Vous pourrez une fois installé utilisé cet outil qui est très utile afin de vérifier que vous pouvez vous connecter depuis "l’extérieur" à votre Lync.

    http://recite.microsoft.com

     

    Bon courage pour la suite,

     

    Hosni

    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    mardi 21 juin 2011 10:12
  • Bonjour,

     

    Excuse moi, je me suis peut-être mal exprimé.

    Les URLs simples sur ton FE sont destinés à être redirigés en internes. Tu vas donc créer des enregistrement de type A vers ton adresse interne (FE).

    Ces enregistrements tu vas les faire dans ton domain controller (où il y a ton serveur DNS et ton Active Directory).

    Tu vas configurés les mêmes URLs simples mais cette fois ci avec une adresse externe sur ton Edge (avec des enregistrement SRV).

    Pour la dernière question, c'est un peu plus compliqué que cela! voici un exemple concret qui va pouvoir t'aider:

     

    SETUP INFORMATION -
    - Forest has empty root (domain.com) with several child domains, but we are only enabling OCS for child domain 'corp.domain.com' and the root 'domain.com'
    - We are not using a Proxy
    - We are not using a Director


    Internal DNS Entries
                  *  _sipinternaltls._tcp.domain.com over port 5061 and pointing to server1.corp.domain.com
                  *  sip.domain.com pointing to 172.16.8.8
                  *  _sipinternaltls._tcp.corp.domain.com over port 5061 and pointing to server1.corp.domain.com
                  *  sip.corp.domain.com pointing to 172.16.8.8
                  *  OCS Standard pool name defaults to the server name, so this A record already exists (server1.corp.domain.com)

    - OCS R2 Standard running on Windows server 2008.  Member of internal Child domain (server1.corp.domain.com) with IP of 172.16.8.8
                 * UCC certificate issued by GoDaddy with subject name: Server1.corp.domain.com and SANs of sip.domain.com and sip.corp.domain.com

    - Edge Server installed on Windows server 2008 named 'Server2'. Member of workgroup in DMZ (created internal A record for server name as server2.corp.domain.com)
                 * Edge has 2 internal NIC's
                          - Internal NIC with IP of 172.16.8.3
                          - 'DMZ' NIC with IPs of 172.16.1.26 (Access Edge), 172.16.1.27 (WebConference Edge) and 172.16.1.28 (AV Edge)
                                    - unique External IP's are associated with each role
                 * Edge has 3rd party Certificates installed for each role (no internal CA) as follows:
                           - Internal Network Certificate - Standard SSL cert from GoDaddy with subject name of server2.corp.domain.com
                           - Access Role Certificate - UCC Certificate from GoDaddy with subject name of sip.corp.domain.com and SAN of sip.domain.com
                           - Web Conferencing Role Certificate - Standard SSL cert from GoDaddy with subject name of webconference.domain.com
                           - A/V Role Certificate - Standard SSL cert from GoDaddy with subject name of av.domain.com

    Internal DNS entries for Edge:
        - DNS A record for server2.corp.domain.com to internal IP of 172.16.8.3
        - DNS A record for AV.domain.com (resolving to external IP Address 206.195.xxx.72) SHOULD THIS BE POINTING TO INTERNAL DMZ IP INSTEAD?
        - DNS A record for Webconference.domain.com (resolving to external IP Address 206.195.xxx.71) SHOULD THIS BE POINTING TO INTERNAL DMZ IP INSTEAD?

    External DNS entries for Edge:
         - Access Edge - DNS A for sip.corp.domain.com resolving to 206.195.xxx.70
                              - DNS A for sip.domain.com resolving to 206.195.xxx.70
                 - DNS SRV for _sipfederationtls._tcp.corp.domain.com over port 5061
                 - DNS SRV for _sipfederationtls._tcp.domain.com over port 5061
                 - DNS SRV for _sip._tls.corp.domain.com over port 443
                 - DNS SRV for _sip._tls.domain.com over port 443
         - Web Conferencing Edge - DNS A record for WebConference.domain.com resolving to 206.195.xxx.71
         - A/V Edge - DNS A record for AV.domain.com resolving to 206.195.xxx.72

     

    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    mercredi 22 juin 2011 14:35
  • C'est bon j'ai résolu le group expansion. Cela venait de ma segmentation qui fonctionnait mal (groupingID).

    En tout cas, tout fonctionne bien, et sans reverse proxy ;)

     

    Merci encore !


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    lundi 4 juillet 2011 08:34

Toutes les réponses

  • Bonjour,

     

    Puis-je avoir quelques précisions sur votre déploiement :

    -Quel type de déploiement avez vous mis en place? Standard ou Enterprise?

    -Vous avez dit que sur votre réseau d'entreprise les appels téléphoniques marchaient bien, ce sont des appels externes? ou "simplement" des appels on-net?

    -Avec quels opérateur avez vous mis en place la configuration de Lync?

    -Quels sont les paramètres de votre Mediation Server?

    -Enfin, vous est-il possible d'envoyer une trace Wireshark afin que l'on puisse voir le routage de l'appel (depuis le mediation server)?

    Vu les premiers éléments dont vous nous faites part, je pense à une restriction d'adresse IP:

    --> Soit de votre côté (essayez de faire un test en désactivant le firewall)  (pas très recommandé mais bon...)

    --> Soit du côté de votre ITSP vérifiez que vous pouvez bien appeler depuis votre adresse IP, ils doivent normalement n'autoriser que l'adresse IP publique de votre organisation.

     

    Vous n'utilisez pas de serveur Edge, et vous pouvez accéder à votre Lync à distance, vous utiliser une version de Lync multitenant, online ou un service similaire? ou vous attaquer simplement votre Lync via un lien IP dédié (type VPN)?

     

    lundi 20 juin 2011 14:30
  • J'ai déployé Lync standard sur un serveur dédié. Le serveur n'est donc pas membre du domaine de mon entreprise mais membre d'un domaine d'une infrastructure de serveur dédié.

    Je n'ai pas de serveur de méditation ni de serveur edge, je veux utiliser Lync uniquement pour la visio-conférence. J'ai publié mon serveur lync sur internet et j'arrive à y accéder via le client, j'arrive à discuter en t'chat avec les autres utilisateurs de ma société. je n'utilise pas de VPN !

    Lorsque je suis sur le LAN de ma société  (avec accès internet) les appels PC-PC entre deux utilisateurs fonctionne très bien. En revanche, et c'est assez étrange, en dehors du LAN de ma société (alors que le serveur n'est pas du tout situé sur celui ci) les appels PC-PC ne fonctionne plus. Tout le reste est OK.

    Ai-je réellement besoin d'un EDGE dans ma topologie ? Pensez-vous que le fait de déployer un EDGE va résoudre mon problème ?

    J'ai déjà fait le test de désactiver les firewall mais c'est la même chose.


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    lundi 20 juin 2011 17:42
  • Bonsoir,

    Je comprends mieux votre problème. Je pensais que vous vouliez utiliser les fonctions d'appels vers du PSTN en passant par un serveur de médiation collocalisé ou non. Dans ce cas là il aurait fallu la version Enterprise de Lync...

    Vous utilisez une version standard, dans laquelle vous retrouvez toutes les fonctions du déploiement enterprise sauf le "Voice Enterprise", et j'étais parti dessus...

     

    Revenons à votre problème, vous me dites que vous avez déployer votre serveur à l'extérieur de votre LAN, or lorsque vous appelé dans votre LAN d'un PC à l'autre tout fonctionne...

    Le problème? LE NAT j'en suis quasi sur! Essayez depuis chez vous de vous connectez à deux client Lync sur le même sous réseau.

    Je pense que le déploiement va marcher si vos clients sont dans le même subnet, c'est pourquoi il fonctionne dans votre LAN entre deux PC.

    Je pense que vous n'échapperez pas au serveur Edge, c'est son rôle, si vous voulez permettre l'accès aux utilisateurs externes à Lync.

    Voici un lien qui vous sera utile (déployer un serveur Edge):

    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=85c62b26-e509-435e-811f-71c8c89dca83

    Tenez moi au courant si le problème est du au NAT, je peux me tromper, mais bon...

    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    lundi 20 juin 2011 21:16
  • Je pense également que cela va fonctionner si je lance 2 clients Lync chez moi et que je test un appel. Comment régler le soucis du NAT ? Le fait de déployer un EDGE va agir comme un routeur NAT ?

    Sinon, est-il possible de régler ce problème de NAT sans passer par un EDGE ?

    J'ai lu le document EDGE mais j'ai du mal à cerné son rôle car le serveur FRONT END de Lync à toujours accès à internet... Exemple pour les URL meet, dialin et admin qui doivent être dispo.

    Comment les utilisateurs interagissent avec le EDGE ? Comment sont utilisés les enregistrements AV et autre via le EDGE ?


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    mardi 21 juin 2011 08:44
  • Bonjour,

     

    Le serveur Edge est requis pour permettre l'accès aux utilisateurs externes.

    Effectivement votre serveur Edge va agir comme un "routeur NAT".

    Sur le fait, si il est possible de régler ce problème sans passer par Edge, à priori non.

     

    Ceci va vous aidez à mieux comprendre les rôles de chaque composants (Edge, Reverse Proxy, role director):

    http://technet.microsoft.com/en-us/library/gg425779.aspx

     

    Vous pourrez une fois installé utilisé cet outil qui est très utile afin de vérifier que vous pouvez vous connecter depuis "l’extérieur" à votre Lync.

    http://recite.microsoft.com

     

    Bon courage pour la suite,

     

    Hosni

    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    mardi 21 juin 2011 10:12
  • Merci pour les précisions.

    Puis-je tout de même accéder a mon Lync depuis l'extérieur sans pour autant déployer de reverse proxy. Je sais que cela n'est pas recommandé mais je ne souhaite pas déployer ce type de serveur pour le moment.


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    mardi 21 juin 2011 11:33
  • Comme vous l'avez dit ce n'est pas recommandé.

    Je ne l'ai personnellement pas mis en place sans reverse proxy, mais je pense que cela est "possible".

    Ceci peut avoir des effets de bord, dans un des liens que je vous ai transmis plus haut vous pouvez voir que le reverse proxy est requis pour les applications suivantes:

    Reverse Proxy

    The reverse proxy is required for the following:

    • To allow users to connect to meetings or dial-in conferences using simple URLs
    • To enable external users to download meeting content
    • To enable external users to expand distribution groups
    • To allow the user to obtain a user-based certificate for client certificate based authentication
    • To enable remote users to download files from the Address Book Server or to submit queries to the Address Book Web Query service
    • To enable remote users to obtain updates to client and device software

     

    Il se peut que certaines fonctionnalités ne fonctionnent pas sans le déploiement de celui-ci.
    Tout dépend de ce que vous voulez mettre en place.
    Hosni

     


    mardi 21 juin 2011 12:23
  • Ok merci hadala et concernant le reverse proxy, puis-je l'installer sur la même machine que mon EDGE serveur ?

    Le serveur Lync Front END communique automatiquement avec le EDGE ? Les utilisateurs, lorsqu'ils lancent le client Lync se connecte au serveur Front END, puis, le serveur Front END communique avec le EDGE ?

    Dois-je créer des enregistrements DNS publique de type SRV pour le EDGE alors qu'ils existent pour mon Front END ? (_sip_internaltls,....)

     

    Merci pour ton aide !


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    mercredi 22 juin 2011 08:10
  • Bonjour,

     

    Je ne pense pas que le reverse proxy puisse s'installer sur la même machine. En tout cas je ne l'ai pas fait comme ça.

    Sur votre Lync standard vous pouvez colocaliser les roles (Font End/Media Server/AV conferencing), le role Edge est en dehors de ce serveur, tout comme le Reverse Proxy doit être en dehors de ce dernier.

    Pour ce qui est donc du Reverse proxy je pense qu'il n'est effectivement pas possible de le collocalisé sur la même machine.

    Les utilisateurs se connecte à votre Edge, et c'est lui qui communique avec le Front End. Le serveur Edge va jouerle role d'interface entre votre "internal network" et "l'external network"

     

    Vos serveurs ne communiquent pas automatiquement, il faut simplement les configurer, pour cela tu devra notamment enregistré ta topologie et l'installer sur ton serveur Edge. Toute la procédure (claire et en images) est décrite sur ce site :

    http://www.lynclog.com/2011/03/lync-installation-guide-adding-edge.html

    Il y a différentes parties et cela va je pense vous guider pour effectuer votre déploiement (ce mode opératoire est vraiment intuitif).

    Je pense également que vous devrez supprimer les enregistrements DNS externes pour le FE et les installer "proprement" sur votre edge afin qu'il n'y ai pas de conflits.

    Si vraiment vous voulez minimiser le nombre de machines je vous conseil d'installer Hyper-V server (qui est gratuit), puis de monter tout votre architecture en VM.

     

    Hosni

     

     

    mercredi 22 juin 2011 09:09
  • Ok et donc du coup mon front END à quand même besoin d'être accessible via internet ? C'est lui qui gère les URLs simples du type /meet, je me trompe ?

    Du coup, sur mon Lync client, si je souhaite passer par la configuration manuelle (et non la découverte automatique) je devrais entrer en serveur externe le FQDN de mon EDGE et non de mon Front END ?

    Merci :)

     

    Edit : aurais-tu un bon guide pour la mise en place du reverse + Edge ?


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    mercredi 22 juin 2011 12:44
  • Les URLs simples (meet, dialin, etc...) sur ton FE sont uniquement destinés à être utiliser sur ton internal network, donc il n'a pas besoin d'être accessible sur internet.

    Oui pour la seconde question.

    Pour les guides je me suis servi des liens que je t'es envoyés ci-dessus.

    N'oublie pas l'outil suivant :  http://recite.microsoft.com

    Il va t'être très utile pour vérifier ta connexion externe.

     

    Bon courage!

     

    Hosni


    mercredi 22 juin 2011 12:57
  • Je ne comprend pas très bien pour les URLs simples... pour l'instant sur mon FE elles sont configurées de cette manière :

    https://monserveurfr/sipdomain1/meet

    https://monserveurfr/sipdomain2/meet

    Si elles ne sont utilisées que en interne, qu'elle est l'URL qui va être générée lorsqu'un client va créer un Online Meeting depuis sont client Outlook ?

    Dans la zone DNS de mon sipdomain1, pour l'autodiscover je dois configurer un enregistrement "_sipinternaltls._tcp.sipdomain1" port 5061 qui pointe vers mon EDGE et pas vers mon FE, tu peux confirmer ?

     

    EDIT : ai-je besoin de créer également des enregistrements SRV sur mon DNS local ? Si oui, je dois créer une nouvelle zone pour chaque SIPdomain et faire un SRV ?


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions

    mercredi 22 juin 2011 13:41
  • Bonjour,

     

    Excuse moi, je me suis peut-être mal exprimé.

    Les URLs simples sur ton FE sont destinés à être redirigés en internes. Tu vas donc créer des enregistrement de type A vers ton adresse interne (FE).

    Ces enregistrements tu vas les faire dans ton domain controller (où il y a ton serveur DNS et ton Active Directory).

    Tu vas configurés les mêmes URLs simples mais cette fois ci avec une adresse externe sur ton Edge (avec des enregistrement SRV).

    Pour la dernière question, c'est un peu plus compliqué que cela! voici un exemple concret qui va pouvoir t'aider:

     

    SETUP INFORMATION -
    - Forest has empty root (domain.com) with several child domains, but we are only enabling OCS for child domain 'corp.domain.com' and the root 'domain.com'
    - We are not using a Proxy
    - We are not using a Director


    Internal DNS Entries
                  *  _sipinternaltls._tcp.domain.com over port 5061 and pointing to server1.corp.domain.com
                  *  sip.domain.com pointing to 172.16.8.8
                  *  _sipinternaltls._tcp.corp.domain.com over port 5061 and pointing to server1.corp.domain.com
                  *  sip.corp.domain.com pointing to 172.16.8.8
                  *  OCS Standard pool name defaults to the server name, so this A record already exists (server1.corp.domain.com)

    - OCS R2 Standard running on Windows server 2008.  Member of internal Child domain (server1.corp.domain.com) with IP of 172.16.8.8
                 * UCC certificate issued by GoDaddy with subject name: Server1.corp.domain.com and SANs of sip.domain.com and sip.corp.domain.com

    - Edge Server installed on Windows server 2008 named 'Server2'. Member of workgroup in DMZ (created internal A record for server name as server2.corp.domain.com)
                 * Edge has 2 internal NIC's
                          - Internal NIC with IP of 172.16.8.3
                          - 'DMZ' NIC with IPs of 172.16.1.26 (Access Edge), 172.16.1.27 (WebConference Edge) and 172.16.1.28 (AV Edge)
                                    - unique External IP's are associated with each role
                 * Edge has 3rd party Certificates installed for each role (no internal CA) as follows:
                           - Internal Network Certificate - Standard SSL cert from GoDaddy with subject name of server2.corp.domain.com
                           - Access Role Certificate - UCC Certificate from GoDaddy with subject name of sip.corp.domain.com and SAN of sip.domain.com
                           - Web Conferencing Role Certificate - Standard SSL cert from GoDaddy with subject name of webconference.domain.com
                           - A/V Role Certificate - Standard SSL cert from GoDaddy with subject name of av.domain.com

    Internal DNS entries for Edge:
        - DNS A record for server2.corp.domain.com to internal IP of 172.16.8.3
        - DNS A record for AV.domain.com (resolving to external IP Address 206.195.xxx.72) SHOULD THIS BE POINTING TO INTERNAL DMZ IP INSTEAD?
        - DNS A record for Webconference.domain.com (resolving to external IP Address 206.195.xxx.71) SHOULD THIS BE POINTING TO INTERNAL DMZ IP INSTEAD?

    External DNS entries for Edge:
         - Access Edge - DNS A for sip.corp.domain.com resolving to 206.195.xxx.70
                              - DNS A for sip.domain.com resolving to 206.195.xxx.70
                 - DNS SRV for _sipfederationtls._tcp.corp.domain.com over port 5061
                 - DNS SRV for _sipfederationtls._tcp.domain.com over port 5061
                 - DNS SRV for _sip._tls.corp.domain.com over port 443
                 - DNS SRV for _sip._tls.domain.com over port 443
         - Web Conferencing Edge - DNS A record for WebConference.domain.com resolving to 206.195.xxx.71
         - A/V Edge - DNS A record for AV.domain.com resolving to 206.195.xxx.72

     

    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    mercredi 22 juin 2011 14:35
  • J'ai réussi à faire marcher Lync comme je le souhaitais, merci pour tes explications.

    Je n'utilise pas de reverse proxy et le seul truc qui ne fonctionne pas c'est de pouvoir voir les membres d'un groupe de distribution. Il y a peut etre quelque chose d'autre à faire au niveau du Lync...

    J'ai une derniere question, j'utilise une seul carte réseau sur mon edge avec une seul IP. Mes services ont donc le même FQDN avec des ports différents. J'ai vu, sur internet, qu'on pouvait aussi mettre une IP par service et tout faire tourner en 443.

    La méthode que j'ai mise en place est-elle fortement déconseillée par MS ? As-tu un avis là dessus ?

    jeudi 23 juin 2011 13:37
  • Bonjour,

     

    Désolé pour l'attente (très occupé en ce moment) et content de voir que tu as réussi à faire marcher ton Lync.

    Je ne vois pas en quoi cela pourrait être déconseillé par MS, il demande le 80 et le 443 pour du HTTP et HTTPS, mais bon je n'ai pas d'avis tranchant là dessus.

    Après si tu veux vraiment supporté Lync et l'intégré de la meilleure façon tu aurais peut-être du mettre en place le director, le reverse proxy, etc...

    Ton déploiement est assez spécial mais si ça marche et ca correspond à ce que tu recherches...Well done!

     

    Hosni

     

    mardi 28 juin 2011 10:46
  • Pas de soucis, tu m'as déjà bien aidé ;)

    Pour finir j'ai mis le EDGE avec 3 interfaces et donc tout sur le port 443, c'est plus simple en entreprise car les pare-feu ne bloquent généralement pas ce port.

    Je n'ai pas déployé de reverse proxy ni de edge, j'ai testé les fonctionnalités offertes par ce dernier et globalement tout marche bien.

    La seule chose que je n'arrive pas à faire marcher c'est de pouvoir voir les utilisateurs d'un groupe de distribution, as-tu déjà rencontré ce problème ? J'ai le message "Impossible d'exécuter cette action et la cause est inconnue". J'ai pas mal cherché sur internet les gens disent de tester l'url "https://monpool/groupexpension/ext/service.asmx" mais je tombe sur une erreur 500...

    Quelqu'un à déjà fait fonctionner le group expansion sans reverse ?

    Sinon autre question, j'ai activer la fédération sur mon serveur Lync et j'aimerais discuter avec des utilisateurs msn/windows live. Il faut obligatoirement souscrire à une CAL pour le faire ?

     

     


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    jeudi 30 juin 2011 09:17
  • Hey!

     

    Je te conseille de faire un nouveau sujet pour savoir si quelqu'un a déjà fait fonctionner le  group expansion sans reverse.

    A priori c'est un des rôles du reverse, donc pas possible sans, mais bon qui sait...

     Reverse Proxy

    The reverse proxy is required for the following:

    • To allow users to connect to meetings or dial-in conferences using simple URLs
    • To enable external users to download meeting content
    • To enable external users to expand distribution groups
    • To allow the user to obtain a user-based certificate for client certificate based authentication
    • To enable remote users to download files from the Address Book Server or to submit queries to the Address Book Web Query service
    • To enable remote users to obtain updates to client and device software

    Sinon pour ta dernière question, il faut souscrire à une licence "spécial" PIC (Public IM Connectivity), pour info le prix est d'environ 30 cts par mois et par utilisateur.

    Bonne journée

     

    Hosni

    jeudi 30 juin 2011 09:59
  • C'est bon j'ai résolu le group expansion. Cela venait de ma segmentation qui fonctionnait mal (groupingID).

    En tout cas, tout fonctionne bien, et sans reverse proxy ;)

     

    Merci encore !


    MCITP : Enterprise Messaging Administrator 2010
    Engineer Hosted Exchange solutions
    • Marqué comme réponse JordanOH lundi 4 juillet 2011 08:34
    lundi 4 juillet 2011 08:34