标签: exchange-server

有没有人成功地与SAS 9.1.3或9.2中的微软交换服务器进行交互？我知道可以使用SAS Ent完成.指南4.x,但如果常规SAS能够做到这一点,我对这条路线不感兴趣.

将端口587用于所有客户端到MTA通信的趋势越来越明显.它位于标准跟踪RFC:http://www.ietf.org/rfc/rfc2476.txt

我的问题是"为什么？".为什么有两个SMTP服务器实例在同一台服务器上运行,如果它们都做同样的事情？它提供了什么安全功能,除了给我两个作为管理员进行故障排除的事情.

这似乎是不必要的复杂性,除非ISP阻止端口25,否则不需要.即使这样,如果ISP阻止端口25以防止垃圾邮件,它只是意味着它只需要更多的时间,直到端口587也被阻止,我们将不得不完全使用不同的端口.

看起来我们正在为自己创造更多的工作,而不是解决问题并开始验证SMTP

我有以下收件箱文件夹结构:

Inbox
--ABC
----ABC 2
----ABC 3
--XYZ
----XYZ 2
--123
----123 A
----123 B
----123 C

我正在使用Exchange Web服务和以下代码来查找收件箱文件夹的子文件夹:

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010);

service.AutodiscoverUrl("MyName@MyDomain.com");
Mailbox mb = new Mailbox("MyName@MyDomain.com");

FindFoldersResults findResults = service.FindFolders(
    WellKnownFolderName.Inbox,
    new FolderView(int.MaxValue));

foreach (Folder folder in findResults.Folders)
{
    Console.WriteLine(folder.DisplayName);
}

这部分有效,因为它返回ABC,XYZ和123文件夹; 不幸的是,它没有返回每个文件夹内的文件夹(ABC 2,ABC 3,XYZ 2,123 A,123 B,123 C).

此外,文件夹可能在其中具有多个级别的子文件夹.

如何编写此代码,以便它将返回所有子文件夹,无论它们的嵌套程度如何？

我试图使用Node.js来调用SOAP Exchange EWS服务.我创建了一个简单的http客户端,如下所示:

var https = require('https');

var username = 'user';
var password = 'password';
var auth = 'NTLM ' + new Buffer(username + ":" + password).toString('base64');

var options = {
    host : 'exchangehost',
    port : 443,
    method : 'post',
    path : '/Exchange.asmx',
    headers : { Authorization : auth }
};

var request = https.request(options, function(response) {
    console.log('Status: ' + response.statusCode);
};

request.write('<soapenv:Envelope  ...></soapenv:Envelope>');
request.end();

我收到状态码401,我怀疑是因为我没有做NTLM认证涉及的三个步骤(http://www.innovation.ch/personal/ronald/ntlm.html).有没有人知道Node.js模块直接与Exchange EWS通信或使用NTLM进行身份验证,或者我是否需要自己为Node.js实现该协议？非常感谢任何帮助.

我正在使用EWS Java 1.2,尽管C#中的2.0显示完全相同的问题,而Exchange 2010 SP3,因此在汇总3之前的SP2中有关邮件正文的特定错误不是问题.

长话短说:EWS + Exchange =痛苦.在Exchange中使用EWS,您可以创建约会.您可以指定约会的消息正文是HTML,并为其提供一堆HTML.这将执行某种HTML - > RTF转换,当您在Outlook桌面或Web客户端中查看HTML时,它会破坏HTML.好吧,我们可以将HTML定制为在过程中没有被吃掉但仍然看起来不错的东西.

除非您通过更改邮件正文更新约会时,它真的会吃HTML格式.如果它与您在创建时提供的HTML相同并不重要.第二次保存会破坏它,只留下粗体文本,换行符和制表符.就好像它是显示纯文本的几个小块格式,或者它是从转换后的HTML中显示一个非常精简的RTF.真正令人抓狂的是它只在你更新身体后才会发生.

问题是,我通过检查扩展属性,在MFCMAPI和EWS中查看了这些约会(和相关的MeetingRequests,它们以相同的方式覆盖).首次创建约会时,仅填充RTF正文.纯文本和HTML正文为空,RTF同步,本机正文值为2,这意味着它应显示RTF.好的,这是有道理的.

在更新时,所有三种体型都存在.RTF不同步.本机正文值为3,这意味着它应该显示HTML.我签了MFCMAPI.纯文本正文和RTF正文都显示内存不足错误,但打开属性会正确显示.HTML正文存在.根据文档,这应该发生,这是零的原因.最佳主体算法指出,如果填充了本机主体属性,那么将使用它并且全部完成.嗯,这显然没有发生.如果它由于某种原因没有获得该值,那么它将通过条件链.好吧,条件链表明在这种情况下应该显示HTML正文.MFCMAPI同意导出的项目,因为它显示本机主体是HTML正文.OWA会很好地展示它.但Outlook 2010/2013？不.

我在这里结束了我的智慧.无论我做什么,我都无法让桌面Outlook正确显示身体.它似乎是从根本上破坏了服务器端的东西,但没有列出已知的错误(除了前面提到的SP2预卷3问题,这不是这里的情况),我找不到任何解释为什么更新打破它的文档厉害.我能做的最好的事情就是直接在创建时设置pidTagBodyHtml,并从一开始就将其打破.至少那是一致的.

编辑:我已经实现了RTF解压缩算法来窥视内部.果然,用于新约会的RTF消息正文和用于更新约会的RTF消息正文(其中正文更新为几乎相同的约会)是非常不同的!Exchange遵循两个单独的代码路径服务器端,它打破了正文格式!我看到的唯一可能的解决方案是实现压缩和格式化算法,并在客户端中手动构建有效的RTF主体,这不是一个小小的壮举.

我正在使用EWS托管API 2.2,它在枚举中不显示Exchange版本2016.我可以看到Exchange 2013的版本.那么如何连接到Exchange Server 2016？API是否尚未从Microsoft更新,或者我是否需要使用任何其他API连接到Exchange 2016？

我有一个Web应用程序调用EWS托管API连接到office365.

我在MSDN上关注了EWS Managed API 2.0客户端应用程序入门文档.

在web.config我指定的代理pac:

<configuration>
  <system.net>
    <defaultProxy useDefaultCredentials="false">
      <proxy autoDetect="False" bypassonlocal="True" scriptLocation="http://example.com:8080/proxy.pac" usesystemdefault="False" />
    </defaultProxy>
  </system.net>
  [...]
</configuration>

我尝试以下列方式连接到Exchange:

public static ExchangeService getExchangeService(String username)
{
    ServicePointManager.ServerCertificateValidationCallback = CertificateValidationCallBack;

    ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2013);
    service.Credentials = new WebCredentials(USER_365, PWD_365, DOMAIN_365);
    service.UseDefaultCredentials = true;

    //I've tried both WebProxy settings, this:
    service.WebProxy = WebRequest.GetSystemWebProxy();
    //And this (with no success):
    //service.WebProxy = WebRequest.DefaultWebProxy;

    //I've also tried Autodiscover...
    service.AutodiscoverUrl(USER_365, RedirectionUrlValidationCallback);
    //...and direct url
    //service.Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx"); …

当我尝试通过EWS发送带有内嵌图像(附件)的HTML消息时,这个问题就暴露出来了.但是我退回到最简单的形式,发现我甚至无法发送HTML消息.

我使用的是C#,.NET 4,EWS API 1.1,Exchange Server 2010 SP1.

这是我的代码的核心:

ExchangeConnection = new ExchangeService(ExchangeVersion.Exchange2010_SP1);
ExchangeConnection.Credentials = new WebCredentials(Username, Password, Domain);
ExchangeConnection.Url = new Uri(ServiceURI);

string MailBody = @"<html><head></head><body>
    This is a <b>test</b> <strong>HTML</strong> <em>message</em>.<br><br>
    Did it work?</body></html>";

NewMessage = new EmailMessage(ExchangeConnection);
NewMessage.Subject = "Test HTML Message #001";
NewMessage.Body = MailBody;
NewMessage.Body.BodyType = BodyType.HTML;
NewMessage.ToRecipients.Add("tony@zierniemann.com");
NewMessage.Send();

使用该代码,我收到一条消息,内容如下:

Subject: Test HTML Message #001
Thread-Topic: Test HTML Message #001
Thread-Index: Acuy3U6nqQTa4W4ZQu6ueHPb2nPDPg==
Date: Thu, 13 Jan 2011 04:49:48 +0000
Message-ID: <2FDB41070D0AC24DB5BC8B80751063630B74A5@xxxxx.com>
Accept-Language: en-US
Content-Language: en-US …

我有一个脚本,可以在Microsoft Exchange Server和Active Directory中创建用户.因此,虽然通常用户的名字在西班牙有重音符号或ñ,但我想避免使用用户名,以免在旧系统中造成任何不兼容性.

那么,我怎么能像这样清理一个字符串呢？

$name = "Ramón"

那样的？:

$name = "Ramon"

补充:感谢用户@grapkulec,我正在使用

using Microsoft.Exchange.WebServices.Data;

我正在尝试将电子邮件移动到我已在Outlook中创建的文件夹(使用MS Exchange).到目前为止,我已经能够将电子邮件移动到草稿或其他众所周知的文件夹名称,但没有成功将其移动到我创建的名为"示例"的文件夹中.

foreach (Item email in findResults.Items)
email.Move(WellKnownFolderName.Drafts);

上面的代码有效; 但我不想使用众所周知的文件夹.而且,如果我尝试将代码更改为:

email.Move(Folder.(Example));

要么

email.Move(Folder.["Example"]);

它不移动(在两种情况下都会抛出错误).我已经找到了很多关于如何将电子邮件移动到MSDN,SO和一般C#上的文件夹的示例 - 但仅限于Outlook(草稿,垃圾邮件等)"知名"的文件夹,这些文件不适用于我创建的文件夹.