Questions tagged «microsoft-office-365»

Office 365是Microsoft的基于订阅的云解决方案，可提高业务效率。所有服务器端组件都托管在Microsoft管理的数据中心中。订阅O365的客户可以访问最新的业务生产力软件，并且可以选择“完全基于云”或具有保留一些本地服务器的混合配置。

7
如果Windows商店将“一切”移到云中，它是否仍需要Active Directory？
摆脱这个问题：我真的需要MS Active Directory吗？朝着2014年的新方向发展。 考虑基本的Windows基础结构： 域控制器 Exchange 2007/2010/2013 共享点 的SQL 文件服务器/打印服务器 AD集成DNS 经过AD身份验证的第三方设备（例如，用于联网的802.1X以及某些内容过滤等） IT应用程序/硬件/等上具有AD / LDAP身份验证的“管理”功能。 也许一些KMS的东西 如果愿意，可以加入CA 本地应用 第三方内部应用 现在，让我们将其全部撕掉，并决定我们要进入云计算。我们已经签订了将Exchange / Sharepoint /文件服务迁移到Office 365的合同。SQL现在也将托管在类似Azure的东西上。我们摆脱了对AD-DNS的需求，只需通过简单的Windows DNS服务器运行所有内容即可。我们仍然需要802.1X，如果可能，我们希望对各种云应用程序使用SSO。自行开发和第三方的内部应用程序可能会保留，但可以使用内部用户数据库代替AD身份验证 问题是...我们真的需要Active Directory吗？ 甚至更重要的是，AD本地部署，甚至通过Azure或类似的（ADFS）托管，或者通过Azure或类似的托管的VM运行ADDS。能否/我们应该寻找其他类似第三方的SSO选项，例如http://www.onelogin.com/partners/app-partners/office-365/或类似的东西，即使它简单，也可以提供SSO功能每个用户的LastPass或类似内容？ 如果云中的其他所有内容都满足AD的什么样的合法需求？ 如果将以MS为中心的基础架构将以前依赖于AD的所有内容转移到不依赖AD身份验证的SaaS产品中，是否可以完全不用AD？
4
Outlook 2013：如何重设为“首次运行”状态？
TL; DR 有没有办法通过脚本，powershell，reg删除，通过远程信息交换来重置Outlook 2013，好像没有配置文件一样存在，并且它是首次运行？ 仍在努力解决这一问题，但希望其他人有见识。 场景 这里的许多用户都具有连接到本地Exchange服务器的现有Outlook配置文件。我们正在迁移到Office365。要迁移用户的Outlook，您必须在Outlook中创建新的配置文件，或完全删除旧的配置文件，然后“重新启动”。 我们希望我们的用户重新开始，并为他们的邮件配置文件使用默认的配置文件名称“ Outlook”（而不是自定义名称或第二个配置文件，如“ O36​​5”）。这是因为我们的ERP系统在ERP软件中查找此配置文件以发送电子邮件。 问题 问题是“从头开始”并不是真的从头开始。 如果我从Mail控制面板设置中手动删除默认配置文件“ Outlook” ，则Outlook将在没有配置文件的情况下启动，但会提示您输入配置文件名称： 如果现在输入Outlook新的配置文件名称，我将得到： 如果我进入REGEDIT并查看： HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles 我仍然看到“ Outlook”作为配置文件。 我尝试使用Reg DELETE此键和所有子键，虽然显示“已成功删除”，但没有。 如果我手动删除此配置文件密钥，则可以再次启动Outlook，当提示输入新的配置文件名称时，我可以将Outlook其放入并接受它，让我继续，就好像它是Outlook的新设置一样： 从Outlook 2013的命令行开关（在此处找到）中并没有发现 / cleanprofile仍然存在。 底行问题 有没有办法通过脚本，powershell，reg删除，通过远程信息交换来重置Outlook 2013，好像没有配置文件一样存在，并且它是首次运行？
1
多个域的多个SPF记录
我们最近开始对电子邮件使用Office 365，这要求我们添加值为的DNS TXT记录v=spf1 include:spf.protection.outlook.com -all。我们已经有一条SPF记录v=spf1 include:spf.mandrillapp.com ?all，其中包含我们也使用的SMTP发件人Mandrill 的值。 我担心这可能会引起一些冲突。这两项SPF记录是否对我有效，还是可以解决？
2
部署Office 365 Pro Plus时卸载旧版Office
在Office的批量许可版本（具有MSI部署的版本）中，可以使用OCT创建一个程序包，该程序包将在部署新版本时删除Office的先前版本。 Office 365 Pro Plus仅是即点即用，这意味着OCT将无法使用它。ODT允许对Office 365 Pro Plus进行一些自定义，但似乎缺少删除Office早期版本的功能。 是否可以通过Office 365 Pro Plus部署来做到这一点，还是真的需要创建脚本来检查Office的每个可能版本以及卸载逻辑？
1
未收到发送到mail.protection.outlook.com的邮件
几天来，我们一直在收到许多订阅客户的抱怨，即他们没有收到每日警报邮件。我们在日志中检查服务器是否接受了邮件（MX记录：）example.com.mail.protection.outlook.com，但是所有订阅此服务的客户端都没有在收件箱中收到我们的邮件。客户端邮件服务器无任何错误地接受邮件。 以下是来自我们的sendmail服务器的日志。注意：我们有有效的SPF记录。此外，我们的邮件服务器未在任何地方列入黑名单。邮件包含有关客户端已订阅的我们的服务的HTML嵌入式信息。 to=<xxxx@xxxxx.co.za>, 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) 我们应该怎么做才能解决这个问题？
4
我可以使用Office365或Azure AD作为Active Directory的主记录吗？
我们的业务规模很小，目前不需要在我们办公室内使用域名。我们有一个基本网络和一个运行Windows Server 2008 R2的服务器，其中包含一些文件共享和第三方应用程序。 我们使用Office 365并具有Windows Azure订阅。两者似乎使我们组织的Active Directory保持了很好的同步。（即，两个系统上的数据看起来相同） 我们在应用服务器上运行的所有第三方应用都支持LDAP作为身份提供者，但由于我们没有运行域，因此必须让每个用户为这些服务创建新的登录名/密码。 理想情况下，我们希望使该服务器从Azure / Office 365同步，并允许用户使用其Office365凭据进行身份验证。 我发现的所有文献都谈到了从本地到Azure的同步，但是我们希望从Azure / Office 365到本地服务器同步。我猜我们的本地服务器将成为Office 365目录的联合身份提供程序... 这是否可能，或者我们是否需要一些可以从Azure或Office 365联合身份的第三方LDAP提供程序？
1
在Office 365中进行验证后，Microsoft Exchange Federation信任断开
好的，这一切都是在我们的Office 365安装过程中开始的。根据Microsoft的说法，您必须从Exchange删除本地联合身份验证信任，验证域，然后再将其添加回...否则，在验证域名时会收到模糊的错误消息。 所以我这样做了……除了现在联邦信任被打破了。我从“ Test-FederationTrust -Verbose”中收到以下消息： VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Token Issuer Uri from Federation Metadata: urn:federation:MicrosoftOnline. VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Token Issuer Certificate from Federation Metadata: <snip>. VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : Retrieved Token Issuer Previous Certificate from Federation Metadata: <snip>. VERBOSE: [19:43:14.005 GMT] Test-FederationTrust : …
2
到Office 365的所有外部邮件均失败SPF，在混合部署中被EOP标记为垃圾邮件
简而言之：当EOP（Exchange Online Protection）将电子邮件标记为垃圾邮件（SCL5）且SPF失败时，合法电子邮件将进入垃圾文件夹。所有外部域（例如gmail.com/hp.com/microsoft.com）到客户端的域（contoso.com）都会发生这种情况。 背景信息： 我们正开始将邮箱迁移到Office 365（Exchange Online）。这是混合部署/丰富共存配置，其中： 本地= Exchange 2003（旧版）和2010（为混合部署而安装） 本地= Office 365（Exchange Online） 已将EOP配置为进行SPF检查。 MX记录指向本地，因为我们尚未完成将所有邮箱从本地迁移到Exchange Online的操作。 问题是当外部用户将电子邮件发送到组织中的Office 365邮箱时（邮​​件流：外部->邮件网关->本地邮件服务器-> EOP-> Office 365），EOP执行SPF查找和硬/软失败消息，其接收邮件的邮件网关的外部IP地址面向外部。 （内部部署邮箱不会显示此问题；只有迁移到Office 365的邮箱才会显示。） 插图： 示例1：从Microsoft到O365 Authentication-Results: spf=fail (sender IP is 23.1.4.9) smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com; dkim=none (message not signed) header.d=none; Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate 23.1.4.9 as …
2
Office365 SPF记录的查找过多
出于某些极其荒谬的管理原因，我们在Office365上使用一个邮箱拆分了一个域，这要求我们将其添加include:outlook.com到SPF记录中。问题在于，仅该规则就需要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查找其原因PERMERRORs的严格SPF验证，并与非严格/妥善执行验证完全不可靠/不可预测的验证。 是否有可能include:从ated肿的Outlook.com记录中删除其中3条规则，但仍涵盖O365使用的服务器？ 编辑： 评论员提到我们应该只使用较短的spf.protection.outlook.com记录。虽然这是新闻对我来说，这是更短，这只是一个记录短： 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 编辑² 我想我们可以从技术上简化为： 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.com记录的任何更改。如果有任何更改或添加[上帝禁止]，我们将必须手动更新以反映这一点。 使用我们的实际域名，记录的长度为260个字符，这将需要2个字符串用于TXT记录，老实说，我不相信所有DNS客户端和SPF解析器都会正确接受长度超过255个字节的TXT记录。
3
无法将日历从O365的忙/闲信息共享到外部联合域
我有两个域，我正在尝试通过联盟共享日历的忙/闲信息。SiteA是Exchange 2010 SP2的内部部署。SiteB是Office 365企业版部署。 这两个组织都是通过MSFT网关联合的。 从SiteA到SiteB共享工作，这意味着SiteB的用户可以请求访问SiteA的用户并查看其日历。 无法从SiteB共享到SiteA。 运行Test-OrganizationRelationship显示以下内容： [PS] C:\Windows\system32>Test-OrganizationRelationship -UserIdentity me@site.a -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: …
2
使用错误的电子邮件时区的Outlook 2016（Office 365）
我在台北时区有两个用户。 两者都使用将系统时间正确设置为台北时间的PC。 两者都在同一租户上具有Office 365 E3 Enterprise帐户，并已安装Office 2016。 两者都使用Outlook 2016满足其电子邮件需求，并连接到同一台本地Exchange服务器。 对于一个用户，电子邮件上的所有时间戳正确显示为台北时间。 对于其他用户，电子邮件上的所有时间戳似乎都在使用PST时间。 为什么？ 我在Google上搜索的所有内容似乎都引用了Outlook日历功能中的时区，但它们甚至都没有使用日历。这仅是参考电子邮件时间戳。
3
Postfix中继到Office365
我试图在Linux机器上安装Postfix服务器，以将所有邮件中继到我们的Office365（Exchange，由Microsoft托管）邮件服务器，但是，我不断收到有关发送地址的错误消息： BB338140DC1：to = relay = pod51010.outlook.com [157.56.234.118]：587，延迟= 7.6，延迟= 0.01 / 0 / 2.5 / 5.1，dsn = 5.7.1，状态为退回（主机pod51010.outlook.com [ 157.56.234.118]说：550 5.7.1客户端没有作为该发送者发送的权限（以回复DATA命令的结尾） Office 365要求MAIL FROM和From：标头中的发送地址与用于身份验证的地址相同。我已经尽我所能在配置中想到的一切来使此工作正常。我的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, localhost.localdomain, localhost …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.