[玩转系统] Exchange 混合环境中的自动发现流程 |第 3 部分#3 |第 34 部分#36
作者:精品下载站 日期:2024-12-14 08:52:12 浏览:16 分类:玩电脑
Exchange 混合环境中的自动发现流程 |第 3 部分#3 |第 34 部分#36
当前的文章是上一篇文章的延续,我们将继续详细回顾基于 Exchange 混合环境中的自动发现之旅
Exchange 混合环境中的自动发现流程 |文章系列
当前文章是三篇文章系列中的最后一篇文章。
该系列中的其他文章是:
- Exchange 混合环境中的自动发现流程 |第 1#3 部分 |第 32 部分#36
- Exchange 混合环境中的自动发现流程 |第 2#3 部分 |第 33 部分#36
步骤 16/30:重定向(HTTP 301/302)响应
自动发现客户端被“编程”为使用 HTTP 重定向请求,以防潜在的自动发现端点无法使用 HTTPS 进行通信。
在我们的示例中,由于潜在的自动发现端点无法使用 HTTPS 进行通信,因此自动发现客户端将“退缩”并尝试使用 HTTP 协议联系自动发现端点。
自动发现客户端 HTTP 请求将包括对有关可提供所需信息的“其他自动发现端点”名称的信息的请求。
在我们的场景中,自动发现客户端寻址主机 - autodiscover.o365info2.mail.onmicrosoft.com
autodiscover.o365info2.mail.onmicrosoft.com 主机是一个独特的 Office 365 组件,充当“逻辑路由器”,负责将自动发现客户端重定向到另一个节点或元素(自动发现端点),可以帮助自动发现客户端到达其最终目的地。
在我们的场景中,自动发现端点向其自动发现客户端提供的 HTTP 重定向消息,包括名为
- autodiscover-s.outlook.com的潜在自动发现端点的 URL 地址>
在下图中,我们可以看到具体的自动发现阶段,其中自动发现客户端被重定向到“下一跳” - autodiscover-s.outlook.com
步骤 16/30:分析 ExRCA 连接测试的数据
在Microsoft远程连接分析器结果页面中,我们可以看到以下信息-
自动发现端点回复,使用重定向消息代码 (HTTP 301/302) 并向自动发现客户端提供目标自动发现端点的“完整 URL”地址 - https://autodiscover-s。 Outlook.com/Autodiscover/Autodiscover.xml
Microsoft 连接分析器正在检查主机 autodiscover.o365info2.mail.onmicrosoft.com 是否有到自动发现服务的 HTTP 重定向。已成功收到重定向 (HTTP 301/302) 响应。重定向网址:
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
步骤 17/30:尝试解析主机名 autodiscover-s.outlook.com
自动发现客户端向 DNS 服务器查询主机的 IP 地址 -
autodiscover-s.outlook.com
在我们继续之前,重要的是停下来问自己——
问题1:主机autodiscover-s.outlook.com是谁或是什么?
A1:名为 - autodiscover-s.outlook.com 的主机是一个附加的 Office 365 组件,也充当“逻辑路由器”。
Q1:如果将autodiscover-s.outlook.com也视为逻辑路由器,与之前的HTTP重定向机制有什么区别?
A2:上述过程基于HTTP协议,目前的重定向过程依赖于HTTPS重定向机制。
Q3:那么……HTTP 与 HTTPS 重定向之间的最大区别是什么?
A3:不同之处在于,当使用HTTPS重定向方法时,自动发现客户端将需要验证自动发现端点证书,以便他能够“相信”他,
“重定向游戏”是一个在 Office 365 云环境中实施的令人着迷的概念。
在“标准”Exchange 本地环境中,与其 Exchange 服务器通信的自动发现客户端期望服务器提供包含自动发现端点的 FQDN 或域名的 SSL 证书(如果服务器使用通配符)证书)。
例如,在我们的场景中,自动发现客户端将使用 Alice 电子邮件地址、域名,并且当自动发现客户端启动与 Exchange 服务器的 HTTPS 会话时,自动发现客户端将查看服务器证书以查找主机名 - autodiscover.o365info.com 或域名 - o365info.com
如果服务器证书不包含指定的名称,则自动发现客户端“有义务”停止通信过程,并转向另一种方法或显示错误消息。
在 Office 365 云环境中,有趣的事实是,不存在具有包含“所需主机名”(例如 -
autodiscover.o365info)的公共证书的“真正”Exchange 服务器。 com
实际上,无法为每个 Office 365 租户购买专用的公共证书。
在这种情况下,理论上,自动发现过程应该会失败。
这个“谜团”的解决方案是 - 自动发现客户端将被“指示”与“其他”自动发现端点进行通信,该端点的主机名与自动发现客户端尝试使用的“原始主机名”不同。
如果您是一个多疑的人,您的脑海中可能会出现偏执的想法 - 如果自动发现客户端寻找非常具体的主机名(例如我们场景中的 autodiscover.o365info.com ) )并且“云”将自动发现客户端重定向到其他自动发现端点主机名,例如 - autodiscover-s.outlook.com ,我们如何知道这不是欺诈或欺诈可能导致“自动发现客户端”发现不受信任元素的阴谋?
这种“恐惧”的答案是,自动发现客户端“重定向到”的自动发现端点(autodiscover-s.outlook.com)将必须证明他的身份并通过提供公共证书证明他是值得信赖的。
自动发现端点 - autodiscover-s.outlook.com 拥有一个公共证书,其中包括将由自动发现客户端验证的所有必需“部分”。
只有当所有“证书部分”都经过自动发现客户端的测试和验证后,自动发现客户端才能够“相信”主机 -
autodiscover-s.outlook .com 是可靠的信息来源。
在接下来的部分中,我们将看到 autodiscover-s.outlook.com 并不是我们自动发现之旅中最后的希望,但现在,让我们继续描述自动发现步骤。
自动发现客户端向 DNS 服务器查询主机的 IP 地址 -
autodiscover-s.outlook.com
DNS 答案包括一系列 IP 地址,因为实际上,Office 365 基础设施是几个“节点”或“主机”,它们“扮演”autodiscover-s.outlook 的角色。 com 主机。
步骤 17/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
尝试在 DNS 中解析主机名 autodiscover-s.outlook.com。主机名解析成功。返回的 IP 地址:157.56.241.102、157.56.245.166、157.56.232.166、157.56.245.70、157.56.236.214、157.56.236.6。
步骤 18/30:测试主机 autodiscover-s.outlook.com 上的 TCP 端口 443 以确保其正在侦听并打开
自动发现客户端将尝试验证 autodiscover-s.outlook.com 是否支持 HTTPS 通信。
在我们的场景中,测试成功完成意味着 autodiscover-s.outlook.com 支持 HTTPS 通信。
注意:如果您想知道主机名 - “autodiscover-s”,我找不到主机名中“S”的任何正式解释,但我相信“S”代表安全。
步骤 18/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
自动发现客户端检查目标主机是否可以使用端口 443 (HTTPS) 进行通信。
“HTTPS 测试”的结果是 - 成功。
正在主机 autodiscover-s.outlook.com 上测试 TCP 端口 443,以确保其正在监听并打开。端口打开成功。
步骤19/30:尝试从远程服务器autodiscover-s.outlook.com获取SSL证书
自动发现客户端请求自动发现端点 (autodiscover-s.outlook.com) 通过提供有效的公共证书来证明其身份。
步骤 19/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
- 自动发现客户端请求自动发现端点向其发送证书。
- 自动发现端点发送他的证书。
- 自动发现客户端已成功接受证书。
Microsoft 连接分析器正在尝试从端口 443 上的远程服务器 autodiscover-s.outlook.com 获取 SSL 证书。Microsoft 连接分析器已成功获取远程 SSL 证书。
远程证书主题:CN=outlook。 com、OU=Microsoft Corporation、O=Microsoft Corporation、L=雷德蒙德、S=WA、C=US、发行者:CN=Microsoft IT SSL SHA2、OU=Microsoft IT、O=Microsoft Corporation、L=雷德蒙德、S=华盛顿,C=美国。
在信息详细信息中,我们可以看到该证书“属于”微软公司(OU=Microsoft Corporation),并且该证书包含域名-outlook.com(远程证书主题:CN=outlook.com)。
步骤 20/30:测试 autodiscover-s.outlook.com SSL 证书以确保其有效
自动发现客户端执行的证书验证测试包括三个不同的部分。
1. 验证证书名称
自动发现客户端,使用主机名寻址潜在的自动发现端点 - autodiscover-s.outlook.com
为了能够知道这是有效或可靠的信息来源,自动发现客户端将检查证书是否包含指定的主机名 -
autodiscover-s.outlook.com 或通配符证书场景中的域名 - *.outlook.com。
2. 验证证书信任
服务器提供的公共证书,由CA(证书颁发机构)提供。自动发现客户端还需要验证向服务器提供其证书的 CA 证书。
3.验证证书日期是否有效
自动发现客户端需要验证服务器证书日期是否有效
如果您想阅读有关自动发现、安全机制和证书主题的更多详细信息,请阅读文章:自动发现过程和 Exchange 安全基础结构 |第 20 部分#36
步骤 20/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
1. 验证证书名称
自动发现客户端验证服务器证书是否包含服务器 FQDN 或服务器域名。
正在验证证书名称。证书名称已成功验证。在证书使用者备用名称条目中找到主机名 autodiscover-s.outlook.com。
2. 验证证书信任
- 自动发现客户端验证服务器证书中显示的信任链。
- 自动发现客户端成功地验证了信任链。
正在验证证书信任。该证书是受信任的,并且所有证书都存在于链中。 Microsoft 连接分析器正在尝试为证书 CN=outlook.com、OU=Microsoft Corporation、O=Microsoft Corporation、L=Redmond、S=WA、C=US 构建证书链。
3. 验证证书日期是否有效。
自动发现客户端验证服务器证书是否仍然有效且未过期。
在我们的示例中,测试成功完成意味着服务器证书有效。
测试证书日期以确认证书有效。日期验证通过。证书还没有过期。证书有效。
NotBefore=2/18/2014 11:41:01 PM,NotAfter=2/18/2016 11:41:01 PM
步骤 21/30:检查客户端证书身份验证的 IIS 配置
自动发现客户端,验证目标主机(自动发现端点)是否需要客户端证书。客户证书是客户证明其身份的一种方法。
步骤 21/30:分析 ExRCA 连接测试的数据
在 Microsoft Remote Connectivity Analyzer 结果页面中,我们可以看到这一点。
- 自动发现客户端询问服务器是否需要客户端证书。
- 服务器回复说他不需要客户端证书。
检查客户端证书身份验证的 IIS 配置。未检测到客户端证书身份验证。未配置接受/要求客户端证书。
步骤 22/30:向自动发现端点提供用户凭据
证书验证、测试成功完成并且自动发现客户端可以“信任”目标主机后,自动发现客户端还需要证明其身份。
自动发现客户端将通过提供用户的凭据来识别自己的身份。 ”
(用户名+密码)。
步骤 22/30:分析 ExRCA 连接测试的数据
注意:“提供用户凭据”部分不会出现在 Microsoft Remote Connectivity Analyzer 结果页面中。
步骤 23/30:尝试向 autodiscover-s.outlook.com 发送自动发现 POST 请求
自动发现客户端将尝试向自动发现端点发送自动发现 POST 请求,以获取所需的自动发现信息。
名为 - autodiscover-s.outlook.com 的主机不是我们自动发现旅程中的最后一个节点,而是“附加路由器”,它将将自动发现端点路由到其最终目的地 -他的 Exchange 服务器。
通过使用附加的“HTTPS 重定向”来实现重定向。
自动发现客户端“信任”主机 autodiscover-s.outlook.com,但是
autodiscover-s.outlook.com span> 不是“预期的 Exchange CAS 服务器”。
在我们的特定场景中,autodiscover-s.outlook.com 发送一条 HTTPS 重定向消息,其中包含以下 URL 地址 -
https:// /pod51049.outlook.com/Autodiscover/Autodiscover.xml
自动发现客户端将从该 URL 地址“提取”主机名 - Pod51049.outlook.com,在下一步中,我们将看到自动发现端点尝试通信的过程与此主机一起完成自动发现过程。
在下图中,我们可以看到我们在自动发现旅程中所处的阶段
步骤 23/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
Microsoft 连接分析器正在尝试从用户 [email protected] 的 URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml 检索 XML 自动发现响应。已成功检索自动发现 XML 响应。收到响应自动发现请求的 HTTPS 重定向。重定向 URL 为 https://pod51049.outlook.com/Autodiscover/Autodiscover.xml。
步骤24/30:尝试解析主机名pod51049.outlook.com
自动发现客户端创建一个 DNS 查询,查找名为 - Pod51049.outlook.com 的主机
从 DNS 服务器应答中,我们可以看到此指定主机名 (Pod51049.outlook.com) 的解析包括一系列 IP 地址。
尽管逻辑上假设主机 - Pod51049.outlook.com 是单个服务器,但实际上,主机“Pod51049.outlook.com ”代表为 Office 365 客户端请求提供服务的 Office 365 Exchange 服务器的许多“单元”。
步骤 24/30:分析 ExRCA 连接测试的数据
在Microsoft远程连接分析器结果页面中,我们可以看到映射到指定主机名的IP4和IP6地址的范围。
尝试在 DNS 中解析主机名 pod51049.outlook.com。主机名解析成功。返回的 IP 地址:157.56.250.66、157.56.254.178、132.245.229.146、132.245.226.34、157.56.251.217、157.56.255.60、132.245.210.9、132.245 .212.98, 2a01:111:f400:9434::2, 2a01:111 :f400:9850::2、2a01:111:f400:8000::9、2a01:111:f400:9428::2、2a01:111:f400:9800::12、2a01:111:f400:882a:: 2、2a01:111:f400:803c::2、2a01:111:f400:9814::9
步骤 25/30:测试主机 pod51049.outlook.com 上的 TCP 端口 443,以确保其正在监听并打开。
自动发现客户端将尝试验证名为 - Pod51049.outlook.com 自动发现端点的主机是否支持 HTTPS 通信。
在我们的场景中,测试成功完成意味着 Pod51049.outlook.com 支持 HTTPS 通信。
步骤 25/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
自动发现客户端尝试验证“目标主机”是否支持 HTTPS 协议,答案是“是”。
测试主机 pod51049.outlook.com 上的 TCP 端口 443,以确保其正在侦听并打开。端口打开成功。
步骤 26/30:请求潜在的自动发现端点提供公共服务器证书
自动发现客户端,要求自动发现端点 (Pod51049.outlook.com) 通过提供有效的公共证书来证明其身份。
步骤 26/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
Microsoft 连接分析器正在尝试从端口 443 上的远程服务器 pod51049.outlook.com 获取 SSL 证书。Microsoft 连接分析器已成功获取远程 SSL 证书。
远程证书主题:CN=outlook.com, OU=Exchange、O=Microsoft Corporation、L=雷德蒙德、S=华盛顿、C=US、发行者:CN=Microsoft IT SSL SHA1、OU=Microsoft IT、O=Microsoft Corporation、L=雷德蒙德、S=华盛顿、C=美国。
步骤 27/30:测试 pod51049.outlook.com SSL 证书以确保其有效。
自动发现客户端执行的证书验证测试包括三个不同的部分。
1. 验证证书名称
自动发现客户端使用名为 - Pod51049.outlook.com 的主机来寻址潜在的自动发现端点
为了能够知道这是“真实主机”,自动发现客户端将检查证书是否包含指定的主机名 (Pod51049.outlook.com) 或域名- *.outlook.com
2. 验证证书信任
服务器提供的公共证书,由CA(证书颁发机构)提供。自动发现客户端还需要验证向服务器提供其证书的 CA 证书。
3. 验证证书日期是否有效。
自动发现客户端需要验证服务器证书日期是否有效。
如果您想阅读有关自动发现、安全机制和证书主题的更多详细信息,请阅读文章:自动发现过程和 Exchange 安全基础结构 |第 20 部分#36
步骤 27/30:分析 ExRCA 连接测试的数据
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
1. 验证证书名称
自动发现客户端验证服务器证书是否包含服务器 FQDN 或服务器域名。
正在验证证书名称。证书名称已成功验证。在证书使用者备用名称条目中找到主机名 pod51049.outlook.com。
2. 验证证书信任
- 自动发现客户端验证服务器证书中显示的信任链。
- 自动发现客户端成功地检查了信任链。
正在验证证书信任。该证书是受信任的,并且所有证书都存在于链中。 Microsoft 连接分析器正在尝试为证书 CN=outlook.com、OU=Exchange、O=Microsoft Corporation、L=Redmond、S=Washington、C=US 构建证书链。
已成功构建一个或多个证书链
3. 验证证书日期是否有效。
自动发现客户端验证服务器证书是否仍然有效且未过期。
在我们的示例中,测试成功完成意味着服务器证书有效。
测试证书日期以确认证书有效。日期验证通过。证书还没有过期。证书有效。
NotBefore=7/24/2014 6:34:15 PM,NotAfter=7/23/2016 6:34:15 PM
步骤 28/30:检查客户端证书身份验证的 IIS 配置
自动发现客户端,验证目标主机(自动发现端点)是否需要客户端证书。客户证书是客户证明其身份的方法。
步骤 28/30:分析 ExRCA 连接测试的数据
在Microsoft远程连接分析器结果页面中,我们可以看到
- 自动发现客户端询问服务器是否需要客户端证书。
- 服务器回复说他不需要客户端证书。
检查客户端证书身份验证的 IIS 配置。未检测到客户端证书身份验证。未配置接受/要求客户端证书。
步骤 29/30:向自动发现端点提供用户凭据
证书验证、测试成功完成并且自动发现客户端可以“信任”目标主机后,自动发现客户端还需要证明其身份。
自动发现客户端将通过提供用户的凭据来识别自己的身份“(用户名 +密码)。
步骤 29/30:分析 ExRCA 连接测试的数据
注意:“提供用户凭据”部分不会出现在 Microsoft Remote Connectivity Analyzer 结果页面中。
步骤 30/30:尝试将自动发现 POST 请求发送到潜在的自动发现 URL:https://pod51049.outlook.com/autodiscover/autodiscover.xml
这是混合环境中 Outlook 自动发现之旅的最后一站。
Outlook或者“自动发现客户端”,找到他的Exchange CAS服务器。
在此阶段中,所有“先决条件任务”已成功完成 - 自动发现设法验证自动发现端点身份并将其身份提供给自动发现端点。
最后一步是自动发现端点(名为 - Pod51049.outlook.com)的 Exchange CAS 服务器将生成自动发现响应并将其发送到我们的自动发现客户端。
在我们的场景中,“客户端”是 Outlook 客户端,它将使用自动发现响应中的信息用于两个主要目的:
1.创建新的 Outlook 邮件配置文件
我们场景中的“声明的任务”是让 Alice 能够创建新的 Outlook 邮件配置文件。
自动发现响应中包含的信息将包括使用 Outlook Anywhere 创建新的 Outlook 邮件配置文件所需的所有必需信息设置。
2.使用 Exchange Web 服务的 URL 地址
创建新 Outlook 邮件配置文件的任务完成后,每次 Outlook 需要特定 Exchange 来提供可用性服务(闲/忙)等服务时,Outlook 将使用自动发现答案中包含的不同 Exchange Web 服务的 URL 地址时间)、OAB(离线通讯录)等。
步骤 30/30:分析 ExRCA 连接测试的数据
Exchange CAS 服务器自动发现响应是作为包含大量“信息行”(XML 标签)的 XML 文件实现的。
我们不会详细审查每个“信息银行行”,而是仅检查自动发现响应内容的一小部分样本。
在Microsoft Remote Connectivity Analyzer结果页面中,我们可以看到以下信息:
Microsoft 连接分析器正在尝试从 URL https://pod51049.outlook.com/Autodiscover/Autodiscover.xml 检索用户 [email protected] 的 XML 自动发现响应。
自动发现 XML已成功检索响应。
Exchange 自动发现响应中的信息分为几个部分。
这些部分的目的是 - 为 Outlook 客户端的不同邮件配置文件提供不同的信息。
Exchange 与 Outlook 提供商一样涉及“不同的 Outlook 邮件配置文件”。
不同类型分为EXCH、EXPR 、WEB 和 EXHTTP
EXCH(内部 Outlook Anywhere)和 EXPR(外部 Outlook Anywhere)设置。
在下面的屏幕截图中,我们可以看到 XML 标签的名称以及这些 XML 标签之间包含的信息的示例。
例如:
1。 Outlook GUID\会话 ID
在 Exchange 2013 环境中,Outlook 客户端不使用 Exchange CAS 服务器的名称,而是使用唯一的会话 ID。
唯一会话 ID 的值是通过使用 XML 标记。
2.可用性服务(空闲/繁忙时间)
每次用户访问其日历并要求查看其他用户的忙/闲时间时,Outlook 客户端都会向专用于此目的的 Exchange Web 服务的 URL 地址发送查询。
https://outlook.office365.com/EWS/Exchange.asmx
3.自动回复(外出)
Exchange 自动回复 Web 服务使 Exchange 客户端能够在收件人向其邮箱发送邮件时自动回复。
如果 Exchange 客户端需要创建自动回复响应,则客户端将使用以下 URL地址:
https://outlook.office365.com/EWS/Exchange.asmx
4.离线通讯录
Outlook 邮件配置文件的默认设置是缓存模式。当使用缓存模式选项时,Outlook 客户端将下载“离线”版本的 Exchange 通讯簿。
Outlook 需要知道下载脱机通讯簿所需的确切 URL 地址 + 脱机通讯簿文件或文件版本的名称。
https://outlook.office365.com/OAB/226ce079-2845-4fac-be53-6ccebb70c82a/
在下一个屏幕截图中,我们可以看到 EXPR 部分下的设置(外部 Outlook Anywhere 的设置)。
在这里,我们可以看到仅在使用 Outlook Anywhere 配置文件时相关或独特的其他详细信息。
我们可以看到,在“EXPR 配置文件”(EXPR)下,我们可以看到类似的设置,例如 Exchange Web 服务 URL 地址:
outlook.office365.com
https://outlook.office365.com/EWS/Exchange.asmx
https://outlook.office365.com/EWS/Exchange.asmx
https://outlook.office365.com/OAB/226ce079-2845-4fac-be53-6ccebb70c82a/
此外,还有与 Outlook Anywhere 不同的特定设置,例如身份验证和加密要求。
在我们的示例中,自动发现响应“通知”Outlook 客户端
1. Exchange CAS 服务器的名称
提供 Outlook Anywhere 服务(RPC 代理)的 Exchange CAS 服务器的名称是 - outlook.office365.com
outlook.office365.com
2.加密要求
Outlook 客户端和 Exchange 服务器之间的通信通道必须使用 HTTPS 实现,身份验证协议为 - Basic
On基本
3. RPC\HTTPS 主机名提供程序和公共证书
为了能够验证 Exchange 服务器是否“可靠”并且可以信任,Outlook 客户端将检查服务器证书是否包含 msstd 中描述的值。
msstd:outlook.com;
猜你还喜欢
- 03-30 [玩转系统] 如何用批处理实现关机,注销,重启和锁定计算机
- 02-14 [系统故障] Win10下报错:该文件没有与之关联的应用来执行该操作
- 01-07 [系统问题] Win10--解决锁屏后会断网的问题
- 01-02 [系统技巧] Windows系统如何关闭防火墙保姆式教程,超详细
- 12-15 [玩转系统] 如何在 Windows 10 和 11 上允许多个 RDP 会话
- 12-15 [玩转系统] 查找 Exchange/Microsoft 365 中不活动(未使用)的通讯组列表
- 12-15 [玩转系统] 如何在 Windows 上安装远程服务器管理工具 (RSAT)
- 12-15 [玩转系统] 如何在 Windows 上重置组策略设置
- 12-15 [玩转系统] 如何获取计算机上的本地管理员列表?
- 12-15 [玩转系统] 在 Visual Studio Code 中连接到 MS SQL Server 数据库
- 12-15 [玩转系统] 如何降级 Windows Server 版本或许可证
- 12-15 [玩转系统] 如何允许非管理员用户在 Windows 中启动/停止服务
取消回复欢迎 你 发表评论:
- 精品推荐!
-
- 最新文章
- 热门文章
- 热评文章
[影视] 黑道中人 Alto Knights(2025)剧情 犯罪 历史 电影
[古装剧] [七侠五义][全75集][WEB-MP4/76G][国语无字][1080P][焦恩俊经典]
[实用软件] 虚拟手机号 电话 验证码 注册
[电视剧] 安眠书店/你 第五季 You Season 5 (2025) 【全10集】
[电视剧] 棋士(2025) 4K 1080P【全22集】悬疑 犯罪 王宝强 陈明昊
[软件合集] 25年6月5日 精选软件22个
[软件合集] 25年6月4日 精选软件36个
[短剧] 2025年06月04日 精选+付费短剧推荐33部
[短剧] 2025年06月03日 精选+付费短剧推荐25部
[软件合集] 25年6月3日 精选软件44个
[剧集] [央视][笑傲江湖][2001][DVD-RMVB][高清][40集全]李亚鹏、许晴、苗乙乙
[电视剧] 欢乐颂.5部全 (2016-2024)
[电视剧] [突围] [45集全] [WEB-MP4/每集1.5GB] [国语/内嵌中文字幕] [4K-2160P] [无水印]
[影视] 【稀有资源】香港老片 艺坛照妖镜之96应召名册 (1996)
[剧集] 神经风云(2023)(完结).4K
[剧集] [BT] [TVB] [黑夜彩虹(2003)] [全21集] [粤语中字] [TV-RMVB]
[实用软件] 虚拟手机号 电话 验证码 注册
[资源] B站充电视频合集,包含多位重量级up主,全是大佬真金白银买来的~【99GB】
[影视] 内地绝版高清录像带 [mpg]
[书籍] 古今奇书禁书三教九流资料大合集 猎奇必备珍藏资源PDF版 1.14G
[电视剧] [突围] [45集全] [WEB-MP4/每集1.5GB] [国语/内嵌中文字幕] [4K-2160P] [无水印]
[剧集] [央视][笑傲江湖][2001][DVD-RMVB][高清][40集全]李亚鹏、许晴、苗乙乙
[电影] 美国队长4 4K原盘REMUX 杜比视界 内封简繁英双语字幕 49G
[电影] 死神来了(1-6)大合集!
[软件合集] 25年05月13日 精选软件16个
[精品软件] 25年05月15日 精选软件18个
[绝版资源] 南与北 第1-2季 合集 North and South (1985) /美国/豆瓣: 8.8[1080P][中文字幕]
[软件] 25年05月14日 精选软件57个
[短剧] 2025年05月14日 精选+付费短剧推荐39部
[短剧] 2025年05月15日 精选+付费短剧推荐36部
- 最新评论
-
- 热门tag