Compte exchange 2010 via Outlook
-
vendredi 3 février 2012 12:56
Bonjour,
Je suis actuellement admin dans une société qui a un server 2008 qui est contrôleur
de domaine.
J'ai mis en place un serveur Exchange 2010.
Tous les employés des locaux ont un compte exchange via outlook 2010 ou 2007.
J'ai ensuite des correspondant qui doivent avoir un compte exchange à l'étranger, mais qui ne sont pas dans le domaine.
Ils peuvent accéder à leur compte via OWA, mais est-il possible de leur mettre un compte directement sur outlook avec exchange anywhere.
J'ai essayé de leur fournir un certificat, mais cela ne fonctionne pas.
Est-ce que quelqu'un aurait une idée.
J'avais une autre question, comment faire pour modifier un message d'absence en dehors de mon entreprise ?
j'arrive via owa mais pas depuis un poste en dehors du reseau local.
Merci beaucoup.
Sébastien
Sébastien- Type modifié Florin CiucaMicrosoft Contingent Staff, Owner jeudi 9 février 2012 15:03 attente de feedback
Toutes les réponses
-
vendredi 3 février 2012 17:47Modérateur
Bonsoir,
oui, avec une bonne configuration, et un certificat adéquat, on peut configurer Outlook Anywhere pour accéder à distance depuis Outlook et avoir toutes les fonctionnalités.
Le certificat créé par Microsoft ne fonctionne tel que pour OWA. Il n'est pas vraiment possible de l'utiliser depuis Internet, car il ne peut pas contenir de nom public que les utilisateurs distants pourraient utiliser.
=> Il faut donc générer un nouveau certificat avec des noms locaux et publics, l'affecter aux services, le mettre dans les autorités (du serveur Exchange et de tous les clients), redémarrer tous les services Exchange. Après seulement, il y aura des chances pour que cela fonctionne.
Pour les utilisateurs distants, tant qu'il y a un warning sur le certificat en OWA, Outlook Anywhere ne pourra pas fonctionner.
Qu'appelez-vous "en dehors du réseau local" ? Quand Outlook Anywhere fonctionnera, il y a de forte chance que le reste fonctionne.
A+
Thierry DEMAN. Exchange MVP. https://www.mcpvirtualbusinesscard.com/VBCServer/MVPtdeman/profile (68 MCPs) http://base.faqexchange.info -
vendredi 3 février 2012 18:16
Bonsoir,
En fait, Outlook anywhere fonctionne sur les PCs qui ont été configuré directement dans l'entreprise (sur le réseau local).
Le personnel accède à sa messgerie via Outlook de chez eux.
Sauf que ces personnes ne peuvent pas configurer leurs messages d'absence de chez eux à partir de Outlook (cela fonctionne juste à travers OWA).
Et d'un autre côté, j'ai du personnel à l'étranger qui n'ont jamais eu de Liaison avec notre réseau privé (à l'intérieur de l'entreprise), ils accèdent à partir d'OWA, mais les certificats que je leur ai envoyé ne leur permettent pas d'accèder à notre serveur Exchange depuis l'étranger alors que les autres personnes de l'entreprise y arrivent.
J'ai un autre soucis aussi, mais je ne vois pas d'où cela vient. Tout les matins, Outlook nous demandes de remettre notre mot de passe pour la réception de mail.
Solution, fermer et rouvrir Outlook.
Mais je ne vois pas la configuration à faire pour que cela ne se passe pas.
Notre connexion se fait via l'authentification windows.
Sinon, en journée, nous n'avons pas de problème.
Merci encore Thierry pour votre réponse.
Cordialement.
Sébastien
Sébastien -
vendredi 3 février 2012 18:18
=> Il faut donc générer un nouveau certificat avec des noms locaux et publics, l'affecter aux services, le mettre dans les autorités (du serveur Exchange et de tous les clients), redémarrer tous les services Exchange. Après seulement, il y aura des chances pour que cela fonctionne.
Sébastien -
vendredi 3 février 2012 18:18Oui, tout cela est déjà fait.
Sébastien -
vendredi 3 février 2012 18:39Modérateur
Les fonctionnalités avancées (Free/Busy, Absences, ...) sont basées sur des fonctions en Web Services (répertoire virtuel /EWS) et sur autodiscover !
Ceci peut aussi expliquer que les utilisateurs qui ne passent pas par le réseau local ne puissent configurer facilement leur accès Internet. Manuellement, la configuration devrait être possible. Mais, il faudrait être sur de l'emplacement où le certificat a été mis (dans les autorités de l'ordinateur), de l'authentification utilisée par ces utilisateurs (forme domaine\user), et du mode d'authentification configuré dans le profil.
Pour les utilisateurs internes qui doivent se réauthentifier, c'est probablement que leur accès se fait par RPC/HTTPS au lieu de RPC directs.
On peut vérifier en utilisant la commande "Outlook /rpcdiag" pour voir si le mode d'accès est HTTPS ou TCPIP.
A+
Thierry DEMAN. Exchange MVP. https://www.mcpvirtualbusinesscard.com/VBCServer/MVPtdeman/profile (68 MCPs) http://base.faqexchange.info -
dimanche 5 février 2012 09:56
Bonjour,
Comme le dit Thierry, tu dois avoir soit un problème de résolution DNS, soit un problème d'authentification.
Lorsque tu dis que tes clients Outlook, hors périmètre LAN, n'arrivent pas à se connecter à Outlook, où se situe vraiment le problème ? Est-ce la configuration du compte dans le profil qui échoue ? Ou est-ce l'accès RPC/HTTPS ?
Quelle méthode d'authentification utilises-tu sur Outlook Anywhere ? Basic ou NTLM ?
Sur l'un de ces postes, la connexion OWA semble fonctionner, mais l'utilisateur reçoit-il un message d'avertissement de sécurité sur son navigateur ? Dans l'absolue, il faudrait vérifier tous les noms DNS publiés https://autodiscover.... etc
Je te conseille de faire quelques tests https://www.testexchangeconnectivity.com/ qui pourraient te révéler quelques mauvaises configurations.
Tiens nous au courant
@+
-
lundi 6 février 2012 20:36
Merci pour vos conseils,
Je fais un test de chez moi, avec un pc qui n'a jamais été dans mon entreprise.
J'ai installé le certificat racine dans "Autorités de certification racines de confiance", je n'ai pas d'avertissement lors
de l'ouverture de la page quand je vais sur OWA.
Dans Outlook, il faut que je créai une nouvelle connexion HTTP ou microsoft Exchange? enfin, j'arrive avec ni l'un ni l'autre.
Mon pc perso n'est pas dans le domaine, cela ne change rien?
J'ai mon collègue, (il avait installé exchange dans l'entreprise), il a pour erreur : autodiscover error 12175 et 12007. (de chez lui)
Autodiscover et EWS sont-ils liés ?
merci encore
Sébastien -
lundi 6 février 2012 20:49
Tu dois choisir de créer un compte "Microsoft Exchange". Pour ton poste qui n'est pas dans le domaine, cela ne doit pas être un problème. On peut très bien configurer un compte Exchange, depuis l'extérieur, sur un poste en workgroup ou dans un autre domaine.
Autodiscover et EWS sont liés par le fait que se sont des webservices Exchange.
Ton autodiscover doit être publié sur l'extérieur en HTTPS avec un FQDN commençant par autodiscover.nomdomaine.tld (ou nomdomaine.tld correspond à tes domaines de messagerie). Il est vivement conseillé d'avoir un certificat public répondant à ce(s) nom(s) sur la publication.
Le test "Découverte Automatique outlook" de https://www.testexchangeconnectivity.com doit pouvoir t'en dire plus sur ta configuration.
- Modifié YvanV mardi 7 février 2012 06:59
-
mardi 7 février 2012 13:45Sur le lien donné, tous les tests doivent fonctionner ?
Sébastien
-
mardi 7 février 2012 13:54
Oui, normalement, ils devraient. Après, toutes les erreurs ne sont pas nécessairement bloquantes. Lesquelles rencontres-tu ?
-
mardi 7 février 2012 14:21
Par exemple : pour la synchronisation, etc.. :
Échec du test de connectivité
Détails du test
Synchronisation, notification, disponibilité et réponses automatiques (absence du bureau) des services Web Exchange.
Certains tests de tâches de services Web Exchange n'ont pas été effectués.
Étapes de test
Assurez-vous que le dossier de boîtes aux lettres de test est vide et accessible.
ExRCA n'a pas pu vérifier que le dossier est accessible et vide.
Détails supplémentaires
Détails de l’exception :
Message : The request failed. The remote server returned an error: (405) Method Not Allowed.
Type : Microsoft.Exchange.WebServices.Data.ServiceRequestException
Trace de pile :
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)
at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToFolder[TFolder](FolderId folderId, PropertySet propertySet)
at Microsoft.Exchange.Tools.ExRca.Tests.EnsureEmptyFolderTest.PerformTestReally()
Détails de l’exception :
Message : The remote server returned an error: (405) Method Not Allowed.
Type : System.Net.WebException
Trace de pile :
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()
at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)Sébastien
-
mardi 7 février 2012 14:37
Il ne doit pas y avoir de données dans la boîte aux lettres utilisée pour ce test. Elle doit être vide.
-
mardi 7 février 2012 14:52
C'est effectivement une boite vide!!!
Est ce que le certificat doit-être obligatoirement public ?
J'ai pas mal de pb de certificats aussi, ils y a qui passent et pas d'autres.
"Certificate trust validation failed" par exemple
j'ai le test de découverte automatique "autodiscover" qui echoue aussi.
Tentative pour localiser l'enregistrement SRV_autodiscover._tcp.mondomaine dans DNS echoue.
A tout hasard, est ce que Exchange peut générer des plannings d'absences à partir des calendriers des utilisateurs ?
Merci encore !
Sébastien
-
mardi 7 février 2012 21:16
Techniquement les certificats publics ne sont pas obligatoires, mais vivement recommandés notamment pour les périphériques mobiles.
Peux-tu nous dire si un test autodiscover depuis l'extérieur fonctionne ?
-
jeudi 9 février 2012 09:27
bonjour,
un certificat publique n'est pas obligatoire, peux tu vérifier si tu as bien dans le DNS publique autodiscover.nomdedomainepublique
soit en alias de ton url owa externe soit en pointeur A avec l'ip publique, dans les 2 cas le certificat doit contenir le fqdn de l'autodiscover + le fqdn de url OWA.
il faut vérifier sur ton firewall (ex TMG) que tu laisse passer /rpc/*, /EWS/* et /autodiscover/*
comme tu as des pc qui sont hors du domaine, je te conseil vivement l'authentification de base.
Geoffrey,
-
vendredi 10 février 2012 15:25
Pour tester l'autodiscover de l'extérieur je reprend le lien que tu m'as donné mais de chez moi ?Techniquement les certificats publics ne sont pas obligatoires, mais vivement recommandés notamment pour les périphériques mobiles.
Peux-tu nous dire si un test autodiscover depuis l'extérieur fonctionne ?
Sébastien
-
vendredi 10 février 2012 15:31
bonjour,
un certificat publique n'est pas obligatoire, peux tu vérifier si tu as bien dans le DNS publique autodiscover.nomdedomainepublique
soit en alias de ton url owa externe soit en pointeur A avec l'ip publique, dans les 2 cas le certificat doit contenir le fqdn de l'autodiscover + le fqdn de url OWA.
il faut vérifier sur ton firewall (ex TMG) que tu laisse passer /rpc/*, /EWS/* et /autodiscover/*
comme tu as des pc qui sont hors du domaine, je te conseil vivement l'authentification de base.
Geoffrey,
Merci pour ta réponse, je regarderai ça.
Je sais, que autodiscover.nomde domainepublique est renseigné dans le dns publique.
Une question :
Mon url pour accéder à owa depuis l'extérieur est : mail.contose.com/owa
dans le dns publique, j'ai donc rentré autodiscover.contose.com, c'est bien ça?
Sébastien
-
vendredi 10 février 2012 15:35
J'ai autre soucis que je viens de voir.
Chez certains utilisateurs quand je fais ctrl + clic droit sur l'icone outlook (en bas à droite) et que je choisis "état de la connexion" , je m'aperçois que dossiers publics est bien en TCP/IP mais courrier, répertoire et courrier sont en https .
Que puis-je faire pour que tout soit en TCP/IP comme bcp d'utilisateurs.
Je ne vois pas si cela vient d'Exchange ou d'Outlook.
Merci encore pour votre aide.
Sébastien
Sébastien
-
vendredi 10 février 2012 15:41Modérateur
Bonjour,
Le mode HTTPS peut être utilisé pour plusieurs raisons :
* si les serveurs CAS ne peuvent pas être connectés avec les ports RPC (dynamiques)=> Vérifier les parefeux...
* si les clients Outlook ont été configurés (dans des propriétés de la configuration Outlook Anywhere) avec les cases cochées pour utiliser en priorité HTTPS sur les réseaux "lents" et les réseaux "rapides".
A+
Thierry DEMAN. Exchange MVP. https://www.mcpvirtualbusinesscard.com/VBCServer/MVPtdeman/profile (68 MCPs) http://base.faqexchange.info
-
vendredi 10 février 2012 15:44
Par défaut, Outlook détecte les connexions réseaux de type lentes et bascule automatiquement la connexion vers HTTPS.
Si tu veux que les connexions soient toujours en TCP/IP il faut configurer les clients en conséquence, cf ci-dessous :
Il faut décocher les cases encadrées en rouge pour que les connexions s'effectuent toujours en TCP/IP (sur LAN). Sur l'extérieur, il est bien entendu normal que les clients soient connectés en HTTPS sur Exchange.
@+
-
vendredi 10 février 2012 15:44
Bonjour Sebastien
la connexion aux dossiers publics passent forcement par le tcp/ip car elle est en directe sur le serveur mailbox.
tu peux forcer la connexion de tes clients depuis Outlook pour utiliser le tcp/ip plutot que le https (quand ils sont connectés sur le reseau local)
1. aller dans le profil outlook
2. parametres...
3. onglet connexion
4. bouton Exchange proxy settings
et regarde dans : "sur les reseaux rapides, connecté d'abord HTTP...": la case doit etre cochée
Merci
- Modifié Hakim T vendredi 10 février 2012 15:45
-
lundi 13 février 2012 05:05
Bonjour,
Pour l'instant j'arrive juste à connecté Outlook en pop/smtp hors domaine,
je n'arrive toujours pas à me connecter directement à Exchange.
Au niveau du pare feu, comment laisser passer /rpc/*, /EWS/* et /autodiscover/* , il y a des ports spécifiques ?
Merci
Sébastien
Sébastien
-
mardi 14 février 2012 13:02
bonjour,
le port sera toujours le 443 (https), par contre si tu n'as pas de systéme firewall/reverse proxy pour publier tes services exchange (ISA Server, TMG Server), tu ne pourras pas sécurisé les paths. donc par la même occasion tu laisse tout passer /*
pour l'autodiscover, c'est ok.
l' url externe doit être par ex : mail.contose.com
peux tu faire un Get-Outlookprovider | fl puis nous retourner le résultat.
vérifie les paramêtres proxy exchange dans le client outlook et nous mettre le résultat.
tu utilise quel type de firewall ?- Modifié Geof62970 mardi 14 février 2012 13:06
-
mardi 14 février 2012 15:35
bonjour,
j'ai un firewall sur un materiel alcatel (omnipcx),
y a t-il un moyen de savoir si le firewall est un firewall/reverse ?
l'url externe est configurer comme celle-ci
la commande demandé se fait sur le powershell exchange ?
les paramètres proxy exchange dans outlook sont :
dans sécurité du comptes de messagerie :
- chiffrement coché
- sécurité de connexion du réseau : Authentification par négociation
Dans les paramètres proxy Microsoft Exchange :
- url : https:// mail.conso.com
- se connecter... msstd:mail.conso.com
sur des réseaux décochés (pour les deux)
Paramètres d'authentification proxy : Authentification de base
Merci
Sébastien
Sébastien
-
vendredi 17 février 2012 10:49
bonjour,
les parametres me semble correct, sauf qu'il faut laisser coché http sur tcp/ip pour les réseau lent.
dans la console exchange graphique, peux tu vérifier l'authentification de outlook anywhere
tu vas dans la partis server/client access à droite faire clic droit sur le serveur outlook anywhere, vérifier que tu es bien en authentification de base et que le nom d'hôte est bien mail.conso.com par exemple
Geoffrey,
-
vendredi 17 février 2012 15:07
Bonjour,
Oui j'ai bien l'authentification de base et le nom d'hôte est bien du style mail.conso.com
et la case ssl en dessous est décoché!
Pas de soucis pour le pop et smtp.
mais dès que je configure un compte (hors domaine) en mode exchange, le serveur exchange n'est pas reconnu (introuvable).
Merci
Sébastien
Sébastien
-
vendredi 17 février 2012 15:11ton nom de domaine externe est il différent du domaine interne ?
MCITP Exchange 2010 Si ma réponse vous a été utile, ou apporté une résolution, merci de voter ou de la marquer comme réponse.
-
dimanche 19 février 2012 19:20Oui, Pour se connecter en interne, c'est sous la forme mail.parc.conso.com et en externe, c'est sous la forme mail.conso.com .
Sébastien
-
lundi 20 février 2012 08:47
bonjour,
peux tu faire
get-autodiscovervirtualdirectory | ft internalurl, externalurl
si rien n'est définis, tu peux faire
get-autodiscovervirtualdirectory | set-autodiscovervirtualdirectory -internalurl https://mail.parc.conso.com/autodiscover/autodiscover.xml -externalurl https://mail.conso.com/autodiscover/autodiscover.xml -WindowsAuthentication $true -BasicAuthentication $true
cela va te paramétrer les urls interne et externe de l'autodiscover puis forcer l'authentification basic et NTLM
Geoffrey,
MCITP Exchange 2010 Si ma réponse vous a été utile, ou apporté une résolution, merci de voter ou de la marquer comme réponse.
- Modifié Geof62970 lundi 20 février 2012 08:47
-
lundi 20 février 2012 16:32
Bonjour,Sans faire les manips au-dessus, de chez moi, j'ai réussi à rejoindre le serveur Exchange avec des
paramètres personnalisés et notamment en choisissant une connexion par internet et .
Par-contre (je suis bien en MAPI, et je vois bien la liste des contacts), je n'arrive pas à voir les calendriers des utilisateurs (disponible ou non disponible) chose à laquelle j'ai accès depuis l'intranet.
Ca me met au niveau du calendrier de l'utilisateur "aucune connexion".
Je n'arrive pas non plus à mettre un message d'absence.
J'y ai juste accès par OWA.
Sébastien
-
jeudi 1 mars 2012 15:18
Voici ce que me demandait Geof62970
"peux tu faire un Get-Outlookprovider | fl puis nous retourner le résultat"
[PS] C:\Windows\system32>Get-Outlookprovider | fl
RunspaceId : e15ede7f-1f0c-fed4-ae84-c34d50cf9366
CertPrincipalName :
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : EXCH
DistinguishedName : CN=EXCH,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=serveurexchange,CN=Microsoft Exchange,CN=Ser
vices,CN=Configuration,DC=company,DC=deux,DC=com
Identity : EXCH
Guid : 6228575f-75f0-4758-5492-5476584fdcc7
ObjectCategory : company.deux.com/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass : {top, msExchAutoDiscoverConfig}
WhenChanged : 18/11/2011 10:33:18
WhenCreated : 18/11/2011 10:33:18
WhenChangedUTC : 18/11/2011 09:33:18
WhenCreatedUTC : 18/11/2011 09:33:18
OrganizationId :
OriginatingServer : serveur-w2k8.company.deux.com
IsValid : True
RunspaceId : e15ede7f-1f0c-4def-84ae-c34d50cf9366
CertPrincipalName :
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : EXPR
DistinguishedName : CN=EXPR,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=serveurexchange,CN=Microsoft Exchange,CN=Ser
vices,CN=Configuration,DC=company,DC=deux,DC=com
Identity : EXPR
Guid : f0eca848-64ac-4774-249a-eaff1b5467f0
ObjectCategory : company.deux.com/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass : {top, msExchAutoDiscoverConfig}
WhenChanged : 18/11/2011 10:33:18
WhenCreated : 18/11/2011 10:33:18
WhenChangedUTC : 18/11/2011 09:33:18
WhenCreatedUTC : 18/11/2011 09:33:18
OrganizationId :
OriginatingServer : serveurw2k8.company.deux.com
IsValid : True
RunspaceId : e15ede7f-1f0c-4def-84ae-c34d50cf9366
CertPrincipalName :
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : WEB
DistinguishedName : CN=WEB,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=serveurexchange,CN=Microsoft Exchange,CN=Serv
ices,CN=Configuration,DC=company,DC=deux,DC=com
Identity : WEB
Guid : 0c8c18b0-aa61-4213-47f8-ed9eadb30375
ObjectCategory : company.deux.com/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass : {top, msExchAutoDiscoverConfig}
WhenChanged : 18/11/2011 10:33:18
WhenCreated : 18/11/2011 10:33:18
WhenChangedUTC : 18/11/2011 09:33:18
WhenCreatedUTC : 18/11/2011 09:33:18
OrganizationId :
OriginatingServer : serveurw2k8.company.deux.com
IsValid : True
Sébastien
-
mardi 6 mars 2012 23:53
Hello ,
bon j’essaierai d'expliquer un peu
OWA :
Outlook Web Access -> utiliser IIS (Web) pour avoir tes mails ..
le serveur Web fonctionnera avec HTTPS --> certificat --> ce certificat doit être reconnu par le navigateur IE ;) -> achète une après d'une autorité de certification reconnu (je ferai pas la pub pour te donner un exemple , lool ) et installe la sur le IIS ...
Outlook AnyWhere :
au lieu de se connecter directement à Exchange via les appel RPC (en utilisant l’authentification NTML - controlleur de domaine - compte windows .. etc etc ) , mais se servir de IIS encore une fois ! ;) (le Web) et faire du RPC Over (au dessus) de HTTP(S) c'est simple;)
(entre () , Outlook Anywhere , permet à MS de faire les offres BPOS et Office 365 )
dans ces deux cas tu as besoin d'un certif reconnus (Internet) car tu utilise le IIS et le Web.
tu peux voir ici
Best Regards
-
mercredi 7 mars 2012 08:35
Bonjour,
Ce qui veut dire qu'avec un certificat auto signé, je ne pourrai pas avoir accès à la gestion des absences et aux calendriers des utilisateurs en dehors de l'entreprise ? (dans Outlook) car sur Owa cela fonctionne !!!
Merci
Sébastien
-
mercredi 7 mars 2012 12:06
non , le fonctionnement des certificats et autorité de certification est un autre sujet.
bon
sur Internet les certificat auto signé (par ta propre autorité de certification : sur ton domaine local eg : mydomain.priv ) ne fonctionnent pas , parce que ces certificats ne seront pas reconnus pour les navigateurs , regardes Option Internet -> contenu -> certificat .
-
mercredi 7 mars 2012 12:24
J'ai intégré le certificat racine dans les autorités de confiance + le certificat personnel sur chaque ordinateur présent hors de notre domaine.
Tout le monde à accès à Outlook (en MAPI) .
Les personnes ont accès à tout sauf à la gestion de leur message d'absence et aux calendriers des autres collègues.
Sébastien
-
mardi 13 mars 2012 16:03
J'ai fais un test de connectivité à microsoft Outlook (via le serveur Exchange), Outlook anywhere (RPC sur HTTP)
Voici le résultat (pas bon) :
Merci
Sébastien
-
mardi 24 avril 2012 09:03
La gestion des absences et calendrier hors domaine est désormais possible.
Orange m'avait mal configurer le nom DNS Autodiscover ! ils se sont trompé dans l'adresse IP d'un chiffre.
Maintenant c'est bon.
Cordialement!
Et encore Merci
Sébastien

