我正在从第三方邮件服务器（MDaemon）迁移到Office 365; 本地Active Directory不包含任何Exchange服务器，从来没有任何。 我们将需要目录同步，以使用户能够使用他们的域凭据login到Office 365; 但似乎只要启用目录同步，就不能在Office 365用户上执行任何操作：所有更改都需要在本地Active Directory上进行，然后由同步进程进行复制。 对于具有单一电子邮件地址和标准function的普通用户来说，这不是一个大问题; 但是那些需要额外地址的用户呢？ 如果我需要configuration一些非标准设置，如“隐藏地址列表”或自定义邮箱配额？ 从我收集的信息来看，唯一受支持的方法是在启用同步后不能直接编辑Office 365对象，而是使用Exchange属性扩展本地AD架构，然后手动编辑它们（！） 。 或者，您可以至less安装一个本地Exchange服务器，然后使用Exchangepipe理工具configuration所需的设置。 这是正确的还是我错过了什么？ 有什么办法来同步用户帐户和密码，但仍然能够直接在Office 365中编辑用户设置？ 如果没有（一切真的需要在本地设置，然后同步），有没有比手动编辑LDAP属性或安装本地Exchange服务器更简单的方法来做到这一点？
我试图在Linux上设置一个Postfix服务器来将所有的邮件转发到我们的Office365（Exchange，由Microsoft托pipe）邮件服务器，但是我一直收到一个有关发送地址的错误： BB338140DC1：to = relay = pod51010.outlook.com [157.56.234.118]：587，delay = 7.6，delay = 0.01 / 0 / 2.5 / 5.1，dsn = 5.7.1，status = bounced（host pod51010.outlook.com [ 157.56.234.118]说：550 5.7.1客户端没有权限发送作为这个发送者（答复到DATA命令结束）） Office 365要求MAIL FROM和From：标头中的发送地址与用于authentication的地址相同。 我已经尝试了一切，我可以在configuration中想到这个工作。 我的postconf -n: append_dot_mydomain = no biff = no config_directory = /etc/postfix debug_peer_list = 127.0.0.1 inet_interfaces = loopback-only inet_protocols = all mailbox_size_limit = 0 mydestination = xxxxx, […]
我们有一个小企业，目前在我们的办公室内不需要域名。 我们有一个基本的networking和一台运行Windows Server 2008 R2的服务器以及一些文件共享和第三方应用程序。 我们使用Office 365并拥有Windows Azure订阅。 这两个似乎保持我们组织的Active Directory非常好。 （即两个系统上的数据看起来相同） 我们在应用程序服务器上运行的所有第三方应用程序都支持LDAP作为身份提供者，但由于我们不运行域，因此我们不得不让每个用户为这些服务创build一个新的login名/密码。 理想情况下，我们希望将此服务器从Azure / Office 365进行同步，并允许用户使用其Office365凭据进行身份validation。 我已经find了所有关于将内部部署同步到Azure的文章，但是我们希望将Azure / Office 365同步到我们的内部服务器上。 我想我们的内部部署服务器成为我们的Office 365目录的联合身份提供者… 这是可能的，还是我们需要一些第三方的LDAP提供者，可以联合从Azure或Office 365的身份？
几天来，我们一直在接受许多我们的订阅客户的投诉，他们没有收到每日警报邮件。 我们检查了我们的日志，邮件被服务器接受（MXlogging： example.com.mail.protection.outlook.com ），但所有订阅此服务的客户都没有收到我们的邮件。 客户邮件服务器接受邮件没有任何错误。 以下是我们的sendmail服务器的日志。 注意：我们有有效的SPFlogging。 另外，我们的邮件服务器不在任何地方列入黑名单。 邮件包含有关我们的客户订阅的服务的HTMLembedded信息。 to=<[email protected]>, delay=00:00:08, xdelay=00:00:08, mailer=esmtp, pri=206583, relay=xxxxx-co-za.mail.p…ction.outlook.com. [xxx.xxx.154.23], dsn=2.0.0, stat=Sent (<VPOP31.4.0e.20140910113951.917.f85.2.34364a7d@CMS1> [InternalId=58007828300753, Hostname=xxxxxxx.eurprd03.prod.outlook.com] Queued mail for delivery) 我们应该怎样做才能解决这个问题？
我在台北时区有两个用户。 两者都使用系统时间正确的台北时间的个人电脑。 两个在同一个租户上都有一个Office 365 E3企业帐户，并安装了Office 2016。 两者都使用Outlook 2016来满足他们的电子邮件需求，并连接到相同的本地Exchange服务器。 对于一位用户，在台北时间，电子邮件上的所有时间戳都是正确的。 对于其他用户，电子邮件上的所有时间标记似乎都是使用PST时间。 为什么？ 一切我谷歌似乎参考Outlook的日历function的时区，但他们甚至不使用他们的日历。 这只是参考电子邮件时间戳。
我有两个域名，我试图通过联合之间共享日历忙/闲信息。 SiteA是Exchange 2010 SP2的内部部署。 SiteB是Office 365企业部署。 两个组织都通过MSFT网关进行联合。 从SiteA到SiteB共享作品，这意味着SiteB的用户可以请求访问SiteA的用户并查看他们的日历。 共享不能从SiteB到SiteA。 运行Test-OrganizationRelationship显示以下内容： [PS] C:\Windows\system32>Test-OrganizationRelationship -UserIdentity [email protected] -Identity siteB -verbose VERBOSE: [20:24:06.006 GMT] Test-OrganizationRelationship : Active Directory session settings for 'Test-OrganizationRelationship' are: View Entire Forest: 'False', Default Scope: 'mydomain', Configuration Domain Controller: 'mydc', Preferred Global Catalog: 'mygc', Preferred Domain Controllers: '{ mydc1, mydc2 }' VERBOSE: [20:24:06.006 GMT] Test-OrganizationRelationship […]
对于一些完全荒谬的行政原因，我们已经在Office365上有一个邮箱的拆分域，这要求我们将include:outlook.com添加到我们的SPFlogging。 这个问题就是这个规则本身就需要9个 DNS查找，最多10个。 严重的是，这太可怕了。 只要看看它： v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4:157.55.9.128/25 include:spfa.bigfish.com include:spfb.bigfish.com include:spfc.bigfish.com include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com ~all 鉴于我们有我们自己的大型邮件系统，我们需要有a ， mx规则， include:_spf1.mydomain.com ，并include:_spf2.mydomain.com这使我们在13个DNS查找导致PERMERROR s严格SPFvalidation器，以及用非严格/严重执行的validation器完全不可靠/不可预测的validation。 是否有可能以某种方式消除其中的3个include:来自臃肿的outlook.comlogging的规则，但仍覆盖O365使用的服务器？ 编辑： 评论者提到我们应该简单地使用较短的spf.protection.outlook.comlogging。 虽然这对我来说是新闻，而且更短，只有一个更短的logging： spf.protection.outlook.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spf.messaging.microsoft.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com Edit² 我想我们可以在技术上削减到： v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all 但是我看到的潜在问题是： 我们需要及时了解父spf.protection.outlook.com和spf.messaging.microsoft.comlogging的任何更改。 如果有什么改变或[神禁止]，我们将不得不手动更新我们的反映。 使用我们的实际域名logging的长度是260个字符，这将需要2个string的TXTlogging，我真的不相信所有的DNS客户端和SPFparsing器在那里将正确接受超过255个字节的TXTlogging。
我们最近开始使用Office 365来处理我们的电子邮件，这需要我们添加一个值为v=spf1 include:spf.protection.outlook.com -all的DNS TXTlogging。 我们已经有一个值为v=spf1 include:spf.mandrillapp.com ?all的SPFloggingv=spf1 include:spf.mandrillapp.com ?all Mandrill，我们也使用一个SMTP发件人。 我担心这可能会导致一些冲突。 这两项SPFlogging对我的关注是否有效？
TL; DR 有没有一种方式通过脚本，PowerShell，reg删除，通过心灵感应，无论重置Outlook 2013，就好像没有configuration文件曾经存在，它有史以来第一次运行？ 仍然在努力通过这一个，但希望别人有见识。 情景 这里的很多用户都有现有的Outlookconfiguration文件连接到内部部署的Exchange服务器。 我们正在迁移到Office 365中。为了迁移用户的Outlook，您必须在Outlook中创build新的configuration文件，或者完全删除旧的configuration文件，然后“重新开始”。 我们希望我们的用户开始新鲜的，他们的邮件configuration文件的默认configuration文件名称为“Outlook”（而不是自定义或第二个configuration文件，如“O365”） 。 这是因为我们的ERP系统在ERP软件中寻找这个configuration文件发送电子邮件。 问题 问题是“开始新鲜”并不是真的开始新鲜。 如果手动从Mail控制面板设置中删除默认configuration文件“Outlook”，则Outlook将启动而不显示configuration文件，但会提示inputconfiguration文件名称： 如果我现在inputOutlook作为新的configuration文件名称，我会得到： 如果我进入REGEDIT并查看： HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles 我仍然将“Outlook”视为一个configuration文件。 我试图做一个Reg DELETE这个键和所有的子键，虽然它说“成功删除”它不。 如果我手动删除此configuration文件密钥，我可以再次启动Outlook，当它提示一个新的configuration文件名称，我可以放在Outlook ，它将采取它，让我继续，如果它是一个新的Outlook设置： 它不会从Outlook 2013的命令行开关（ 在此处find ）显示/ cleanprofile仍在。 底线问题 有没有一种方式通过脚本，PowerShell，reg删除，通过心动过速，无论重置Outlook 2013，就好像没有configuration文件曾经存在，它是有史以来第一次运行？
从这个问题分离出来： 我真的需要MS Active Directory吗？ 在2014年新的方向。 考虑到基本的Windows基础结构： 域控制器 Exchange 2007/2010/2013 的SharePoint SQL 文件服务器/打印服务器 AD集成DNS ADauthentication的第三方设备（比如802.1X用于networking连接，也可能是一些内容过滤等） AD / LDAP在IT应用程序/硬件等上validation了“pipe理”function。 也许一些KMS的东西 如果你愿意，可以投入CA. 家庭应用程序 第三方内部应用程序 现在，让我们把所有的东西全部搞定，并决定我们要去云端。 我们已经签约将Exchange / Sharepoint /文件服务迁移到Office 365中。现在，SQL也将托pipe在Azure之类的东西上。 我们已经不再需要AD-DNS，只需通过一个简单的Windows DNS服务器就可以运行所有的事情。 我们仍然需要802.1X，如果可能的话，也希望SSO能够用于我们的各种云应用。 本土和第三方内部应用程序可能会停留，但有能力使用内部用户数据库，而不是ADauthentication 问题是…我们真的需要Active Directory吗？ 或者更重要的是，AD内部部署，甚至通过Azure或类似的（ADFS）托pipe，或通过Azure或类似的方式在托pipe的虚拟机上运行ADDS。 我们是否可以/我们应该看看像第三方SSO选项，如http://www.onelogin.com/partners/app-partners/office-365/或类似的，可以提供SSOfunction，即使它是一样简单LastPass或类似的每个用户？ 如果云中的其他东西都能满足AD的合理需求， 如果一个以MS为中心的基础设施能够将以前依赖于AD的所有东西移动到不依赖于AD身份validation的SaaS产品中，那么它们是否可以摆脱？