In 'n bestaande on-premises EWS Managed API-toepassing ken u die tussenganger voor die HTTP-bewerkings aan die diens toe:

using System.Net;

var proxy = new WebProxy("http://proxy.example:8080")
{
    Credentials = new NetworkCredential(proxyUser, proxyPassword)
};
exchangeService.WebProxy = proxy;

exchangeService hou reeds die EWS-eindpunt en diensinstellings. Die Credentials daarvan is die Exchange-rekening; proxy.Credentials is die tussengangerrekening. Die diens se opsie vir verstekgeloofsbriewe vul nie daardie proxy-objek outomaties nie.

Vir 'n doelbewuste direkte verbinding in hierdie API-stapel:

exchangeService.WebProxy = new WebProxy();

'n Leë WebProxy kies direkte gedrag. 'n Nul-waarde WebProxy op die diens laat eerder die onderliggende versoek se verstek-proxybeleid in plek.

Vir net een on-premises gasheer gebruik u die beoogde omsyfer wat by die werklike spelling en nie-verstekpoort pas, eerder as om die masjienwye roete te verander. Vergelyk die EWS-URL en die proxy-objek wanneer Outlook werk: daardie ander kliënt kan 'n ander roete en tussengangerrekening hê.

Verwante artikels