月度归档:2017年07月

windows 10 远程桌面 第一次登录之前 你必须更改密码 请更新密码

MSTSC方式登录Windows 2012服务器,登录失败

问题描述

 

对于密码鉴权方式创建的Windows 2012弹性云服务器,使用初始密码以MSTSC方式登录时,登录失败,系统显示“第一次登录之前,你必须更改密码。请更新密码,或者与系统管理员或技术支持联系”。
可能原因

用户本地使用的计算机(即客户机)操作系统为Windows 10。

由于Windows 10操作系统的自身限制,不能以初始密码直接远程连接操作系统为Windows 2012的弹性云服务器。
处理方法

    方法一

    更换使用Windows 7操作系统的计算机作为客户机,远程连接操作系统为Windows 2012的弹性云服务器。

    方法二

    继续使用Windows 10 客户机远程登录,但是,需先修改弹性云服务器的初始密码。
        首次登录,以VNC方式登录操作系统为Windows 2012的弹性云服务器。
        登录成功后,按照界面提示修改弹性云服务器的密码。
        使用修改后的密码,以MSTSC方式远程登录。

    方法三

    继续使用Windows 10 客户机,并以初始密码远程登录。
        单击“开始”菜单,在“搜索程序和文件”中,输入“mstsc”。

        系统进入“远程桌面连接”界面。
        依次输入弹性IP、用户名“administrator”以及创建弹性云服务器时设置的登录密码进行连接。

        连接失败,系统提示“第一次登录之前,你必须更改密码。请更新密码,或者与系统管理员或技术支持联系”。
        单击“远程桌面连接”页面左下角的“选项”。
        在“常规”页签,单击“连接设置”栏的“另存为”,保存“.rdp”格式的远程桌面文件。
        使用Notepad++打开4中保存的远程桌面文件。
        编辑远程桌面文件,在文件的最后一行,添加如下语句并保存。

        enablecredsspsupport:i:0
        双击更新后的“.rdp”文件,打开远程桌面连接。
        单击“连接”,重新连接操作系统为Windows 2012的弹性云服务器。

ascii

点击查看原图

ASCII控制字符

二进制 十进制 十六进制 缩写 可以显示的表示法 名称/意义
0000 0000 0 00 NUL 空字符(Null)
0000 0001 1 01 SOH 标题开始
0000 0010 2 02 STX 本文开始
0000 0011 3 03 ETX 本文结束
0000 0100 4 04 EOT 传输结束
0000 0101 5 05 ENQ 请求
0000 0110 6 06 ACK 确认回应
0000 0111 7 07 BEL 响铃
0000 1000 8 08 BS 退格
0000 1001 9 09 HT 水平定位符号
0000 1010 10 0A LF 换行键
0000 1011 11 0B VT 垂直定位符号
0000 1100 12 0C FF 换页键
0000 1101 13 0D CR 归位键
0000 1110 14 0E SO 取消变换(Shift out)
0000 1111 15 0F SI 启用变换(Shift in)
0001 0000 16 10 DLE 跳出数据通讯
0001 0001 17 11 DC1 设备控制一(XON 启用软件速度控制)
0001 0010 18 12 DC2 设备控制二
0001 0011 19 13 DC3 设备控制三(XOFF 停用软件速度控制)
0001 0100 20 14 DC4 设备控制四
0001 0101 21 15 NAK 确认失败回应
0001 0110 22 16 SYN 同步用暂停
0001 0111 23 17 ETB 区块传输结束
0001 1000 24 18 CAN 取消
0001 1001 25 19 EM 连接介质中断
0001 1010 26 1A SUB 替换
0001 1011 27 1B ESC 跳出
0001 1100 28 1C FS 文件分割符
0001 1101 29 1D GS 组群分隔符
0001 1110 30 1E RS 记录分隔符
0001 1111 31 1F US 单元分隔符
0111 1111 127 7F DEL 删除

ASCII可显示字符

二进制 十进制 十六进制 图形
0010 0000 32 20 (空格)(␠)
0010 0001 33 21 !
0010 0010 34 22 "
0010 0011 35 23 #
0010 0100 36 24 $
0010 0101 37 25  %
0010 0110 38 26 &
0010 0111 39 27 '
0010 1000 40 28 (
0010 1001 41 29 )
0010 1010 42 2A *
0010 1011 43 2B +
0010 1100 44 2C ,
0010 1101 45 2D -
0010 1110 46 2E .
0010 1111 47 2F /
0011 0000 48 30 0
0011 0001 49 31 1
0011 0010 50 32 2
0011 0011 51 33 3
0011 0100 52 34 4
0011 0101 53 35 5
0011 0110 54 36 6
0011 0111 55 37 7
0011 1000 56 38 8
0011 1001 57 39 9
0011 1010 58 3A :
0011 1011 59 3B ;
0011 1100 60 3C <
0011 1101 61 3D =
0011 1110 62 3E >
0011 1111 63 3F ?
二进制 十进制 十六进制 图形
0100 0000 64 40 @
0100 0001 65 41 A
0100 0010 66 42 B
0100 0011 67 43 C
0100 0100 68 44 D
0100 0101 69 45 E
0100 0110 70 46 F
0100 0111 71 47 G
0100 1000 72 48 H
0100 1001 73 49 I
0100 1010 74 4A J
0100 1011 75 4B K
0100 1100 76 4C L
0100 1101 77 4D M
0100 1110 78 4E N
0100 1111 79 4F O
0101 0000 80 50 P
0101 0001 81 51 Q
0101 0010 82 52 R
0101 0011 83 53 S
0101 0100 84 54 T
0101 0101 85 55 U
0101 0110 86 56 V
0101 0111 87 57 W
0101 1000 88 58 X
0101 1001 89 59 Y
0101 1010 90 5A Z
0101 1011 91 5B [
0101 1100 92 5C \
0101 1101 93 5D ]
0101 1110 94 5E ^
0101 1111 95 5F _
二进制 十进制 十六进制 图形
0110 0000 96 60 `
0110 0001 97 61 a
0110 0010 98 62 b
0110 0011 99 63 c
0110 0100 100 64 d
0110 0101 101 65 e
0110 0110 102 66 f
0110 0111 103 67 g
0110 1000 104 68 h
0110 1001 105 69 i
0110 1010 106 6A j
0110 1011 107 6B k
0110 1100 108 6C l
0110 1101 109 6D m
0110 1110 110 6E n
0110 1111 111 6F o
0111 0000 112 70 p
0111 0001 113 71 q
0111 0010 114 72 r
0111 0011 115 73 s
0111 0100 116 74 t
0111 0101 117 75 u
0111 0110 118 76 v
0111 0111 119 77 w
0111 1000 120 78 x
0111 1001 121 79 y
0111 1010 122 7A z
0111 1011 123 7B {
0111 1100 124 7C |
0111 1101 125 7D }
0111 1110 126 7E ~

dmarc

基于域的邮件验证、报告和一致性(DMARC) 这个规范旨在减少邮件滥用(例如通过伪造邮件的“From:
报头来篡改原件的入站垃圾邮件和网络钓鱼邮件。 DMARC 帮助域拥有者使用“域名系统”(DNS)来向收件服务器告知其 DMARC
策略,例如他们希望这些服务器如何处理自称来自他们域但无法验证实际来源的邮件。 收件服务器在处理入站邮件时通过 DNS
查询检索到的这个策略可以向服务器表明应该隔离或拒收不符合这个策略的邮件,或根本不采取任何操作(例如继续照常处理邮件)。 除了这个策略以外,该域的
DMARC DNS 记录也可以包含服务器请求来向某人发送 DMARC
报告、概述自称来自此域的入站邮件的总数、它们是否通过验证、以及任何失败的详细信息。 DMARC
的报告功能在确定您的邮件验证流程是否有效,以及伪造邮件使用您域名的频率时极其有用。

在“安全设置”对话框的“发件人验证”部分中,提供以下三个部分供您配置 MDaemon 的 DMARC 验证和报告功能: DMARC 验证、DMARC 报告和 DMARC 选项。

DMARC 验证

作为 DMARC 验证流程的一部分,MDaemon 对在每封入站邮件的“From:” 报头中找到的域执行 DMARC DNS 查询。 这用来确定该域是否使用 DMARC,如果使用了 DMARC 则检索其“DMARC DNS 记录”,其中包含了它的策略和其他 DMARC 相关信息。 此外,DMARC 使用 SPFDKIM 来验证每封邮件,并要求它至少通过一项测试来通过 DMARC 验证。 如果该邮件通过验证,则按照 MDaemon
其余投递和过滤流程来照常处理这封邮件。 如果未通过验证,则取决于该域的 DMARC 策略以及您对于 MDaemon
如何处理这些邮件的配置来确定该邮件的命运。

如果一封邮件未通过 DMARC 验证,而且 DMARC 域拥有一个“p=none”策略,则不会采取任何惩罚性操作并照常处理这封邮件。 相反,当 DMARC 域拥有一个存在限制的策略,例如“p=quarantine”或“p=reject”,MDaemon 可以有选择性地将该邮件自动过滤到接收用户垃圾邮件的文件夹。 您也可以选择在该域使用“p=reject”策略时,让 MDaemon 完全拒收未通过验证的邮件。 对于使用限制性策略且未通过验证的邮件,MDaemon 将取决于策略插入“X-MDDMARC-Fail-policy: quarantine”或“X-MDDMARC-Fail-policy: reject”报头。 这帮助您使用“内容过滤器”,基于这些报头来执行一些操作,例如将该邮件发送至特定的文件夹进行审核。

建议默认情况下为大多数 MDaemon 配置启用 DMARC 验证。

DMARC 报告


MDaemon 查询 DNS 是否存在 DMARC 记录时,该记录可能包含一些标签,指示域的拥有者是希望接收与声称来自此域邮件相关的
DMARC 综合报告还是故障报告。 “DMARC 报告”屏幕上的一些选项供您用来指定是否希望发送请求的报告类型,并指定这些报告应该包含的元数据。
将在每晚午夜(UTC)发送综合报告,将按邮件来发送故障报告,因为每个发生的事件将触发这个报告。 报告以打包压缩(ZIP)的 XML
文件附件形式发送,而且在线提供各种分析工具,帮助收件人更简便地进行查看。

默认情况下 MDaemon 不发送综合或故障报告。 如果您希望发送这些报告,请在“DMARC 报告”屏幕上启用相应的选项。

DMARC 选项

“DMARC 选项”屏幕包含各种选项,例如在 DKIM 报告中包含特定信息、记录 DMARC DNS 记录、以及更新 MDaemon 用于 DMARC 的“公共后缀”文件。

DMARC 验证和邮件列表

因为 DMARC 的目的在于确保在邮件“From:” 报头中找到的域不被伪造,必须允许发件服务器代表该域来发送邮件。 这会给邮件列表带来一个问题,因为列表通常代表来自外部域的列表成员来分发邮件,并使“From:” 报头保持不变。 这就意味着在收件服务器尝试对这些邮件使用 DMARC 验证时,邮件会被不关联“From:
报头域的服务器发送。 如果 DMARC 域正好使用了存在限制的 DMARC 策略,这会导致邮件被隔离甚至被收件服务器拒收。
在某些情况下,这会导致从列表的成员中删除收件人。 为了避免这个问题,在 MDaemon 发现列表邮件来自使用了受限 DMARC
策略的域时,MDaemon 将使用邮件列表的地址来替换“
From:” 报头。 此外,您也开始配置 MDaemon 在列表邮件来自存在受限策略的域时,拒收这些邮件。 后者使所在域使用了受限策略的用户能够向列表发送邮件。 用来替换“From:” 报头的选项位于邮件列表编辑器的“报头”屏幕。 用来拒收邮件的选项位于“设置”屏幕。

为您的 MDaemon 域使用 DMARC

如果您希望为您自己的域使用
DMARC,这就意味着您希望支持 DMARC 的收件服务器使用 DMARC 来验证声称由您发送的邮件,您首先必须确保您已为该域创建了格式正确的
SPF 和 DKIM DNS 记录;而且您必须使这些选项正确工作来使用 DMARC。 如果您正在使用 DKIM,您也要配置 MDaemon
的“DKIM 签名”选项来签署该域的邮件。 此外,您必须为该域创建一个 DMARC DNS 记录。 通过查询 DNS 是否存在这个拥有特殊格式的
TXT 记录,收件服务器可以确定您的 DMARC 策略和各种可选的参数,例如: 您使用的验证模式、您是否希望接收综合报告、应接收报告的邮件地址等。

一旦您正确配置了
DMARC 并开始接收 DMARC XML 报告,您可以使用大量在线工具来阅读这些报告并诊断任何潜在的问题。 方便起见,在
\MDaemon\App\ 文件夹中还为您提供一个 DMARC Reporter 工具。 请参阅 DMARCReporterReadMe.txt
来获得使用说明。

定义 DMARC TXT 资源记录

以下是 DMARC 记录常用组件的基本概述。 要获得更多详细信息或有关高级配置的更多信息,请参阅: www.dmarc.org.

拥有者字段

DMARC 资源记录的“拥有者”(也叫做“姓名”或“左侧”)字段必须始终为 _dmarc,如果您希望指定该记录应用到的域或子域,也可以采用 _dmarc.domain.name 这种形式。

示例:

example.com 的 DMARC 记录

_dmarc IN TXT “v=DMARC1;p=none”

该记录将应用于发自 user@example.com 或子域为 example.com 的电子邮件,例如 user@support.example.com、user@mail.support.example.com 等。

_dmarc.support.example.com IN TXT “v=DMARC1;p=none”

该记录仅应用于发自 user@support.example.com 的电子邮件,不应用于发自 user@example.com 的电子邮件。

_dmarc.support IN TXT “v=DMARC1;p=none”

该记录将应用于发自: user@support.example.com、user@a.support.example.com、user@a.b.support.example.com 等的电子邮件。

DMARC 记录标签和值

必需标签

标签

备注

v=

DMARC1

这是“版本”标签,必须作为该记录的 DMARC 特定文本部分的第一个标签。 即使其他 DMARC 标签值不区分字母大小写,v= 标签的值必须是大写字母: DMARC1

示例:

_dmarc IN TXT “v=DMARC1;p=none”

p=

none

quarantine

reject

这是“策略”标签,必须作为 DMARC 记录中的第二个标签,紧接 v= 这个标签。

p=none 表示收件服务器基于 DMARC 查询结果不采取任何操作。 不得基于未通过 DMARC 检查这个失败隔离或拒收邮件。 不过可以出于其他理由隔离或拒收这些邮件,例如未通过垃圾邮件过滤测试或与 DMARC 无关的其他安全检查。 对于 p=none 的使用有时被称为“监控”或“监控模式”,因为您可以配合 rua= 这个标签一起使用来从收件域接收有关您邮件的综合报告,不过不会对未通过 DMARC 检查的这些邮件执行任何惩罚性操作。 您可以一直使用这个策略,直到您彻底测试了您的 DMARC 实施,并确保您已准备好使用更具有限制性的 p=quarantine 策略。

p=quarantine 这个策略用于以下场景:在邮件的“From:” 报头声称由您所发送但未通过 DMARC 检查时,您希望其他邮件服务器将该邮件视为可疑邮件。 取决于服务器的本地策略,这可以表示对邮件进行额外审核、将其放入收件人的垃圾邮件文件夹、将其路由到不同的服务器或采取其他操作。

p=reject 表示您希望收件服务器拒收未通过 DMARC 验证的任何邮件。 不过一些服务器仍然接收这些邮件,不过将其隔离或进行额外审核。
这是限制性最高的策略,通常不使用该策略,除非您对自己的邮件策略、以及您允许账户使用的邮件或服务类型把握十足。
例如,如果您允许您的用户加入第三方邮件列表,使用邮件转发服务,并使用网站上的“共享”功能,使用
p=reject 将可能导致一些合法邮件被拒收。 而且该设置也会使某些用户被一些邮件列表删除或阻止。

示例:

_dmarc IN TXT “v=DMARC1;p=quarantine;rua=mailto:dmarc-report@example.net”

额外标签

以下列出的所有标签都是可选标签。 如果未在记录中使用任何这些标签,则假定其默认值。

标签

备注

sp=

none

quarantine

reject

默认值:

如果未使用 sp=,则对域和子域应用 p= 这个标签。

此标签用来指定应用 DMAR 记录的域的子域将使用的策略。 例如,如果应用于 example.com 的记录中使用了这个标签,那么会将 p= 这个标签中指定的策略应用于来自 example.com 的邮件,将 sp= 这个标签中指定的策略应用于来自 example.com 子域的邮件,例如 mail.example.com。如果在记录中忽略了这个标签,则将 p= 这个标签应用于该域及其子域。

示例:

_dmarc IN TXT “v=DMARC1;p=quarantine;sp=reject”

rua=

由逗号分隔的将接收 DMARC 综合报告的邮件地址列表 必须使用以下格式输入作为 URI 的 地址:
mailto:user@example.com

默认值: none

如果未使用这个标签,则不发送综合报告。

此标签表示您希望从接收了一封“From:” 声称来自您所在域邮件的收件服务器接收 DMARC 综合报告。 使用以下格式指定作为 URI 的一个或多个邮件地址: mailto:user@example.com,使用逗号分隔多个 URI。

示例:

_dmarc IN TXT “v=DMARC1;p=quarantine;
rua=mailto:user01@example.com
,mailto:user02@example.com”

通常这些地址将位于此记录覆盖的域。 如果您希望将报告发送至其他域的地址,则该域的 DNS 区域文件必须也包含一个专用的 DMARC 记录,指示它将接收该域的 DMARC 报告。

example.com 的记录示例:

_dmarc IN TXT “v=DMARC1;p=quarantine;
rua=mailto:non-local-user@example.net”

example.net 的记录:

example.com._report._dmarc TXT “v=DMARC1”

ruf=

由逗号分隔的将接收 DMARC 故障报告的邮件地址列表 必须使用以下格式输入作为 URI 的 地址:
mailto:user@example.com

默认值: none

如果未使用这个标签,则不发送故障报告。

此标签表示您希望从接收了一封“From:” 声称来自您所在域邮件的服务器接收 DMARC 故障报告,前提是满足了在 fo= 这个标签中指定的条件。 在默认情况下,如果未指定 fo= 这个标签,在邮件未通过所有 DMARC 验证检查时将发送故障报告(例如未通过 SPF 和 DKIM 验证)。 使用以下格式指定作为 URI 的一个或多个邮件地址: mailto:user@example.com,使用逗号分隔多个 URI。

示例:

_dmarc IN TXT “v=DMARC1;p=quarantine;
ruf=mailto:dmarc-failures@example.com”

通常这些地址将位于此记录覆盖的域。 如果您希望将报告发送至其他域的地址,则该域的 DNS 区域文件必须也包含一个专用的 DMARC 记录,指示它将接收该域的 DMARC 报告。

example.com 的记录示例:

_dmarc IN TXT “v=DMARC1;p=quarantine;
ruf=mailto:non-local-user@example.net”

example.net 的记录:

example.com._report._dmarc TXT “v=DMARC1”

要了解有关 DMARC 规范的更多扩展信息,请参阅: www.dmarc.org

创建记录

在 SPF 和 DKIM 就绪后,您就可以通过 TXT 记录的形式向您的网域的 DNS 记录添加策略,以配置 DMARC(就像对 SPF 或 ADSP 执行的操作一样)。

TXT 记录的名称应该是“_dmarc.your_domain.com.”,其中“your_domain.com”替换为您的实际域名。

下面是 DMARC TXT 记录中的常用标记:

标记名称 必填 用途 样例

v

必需 协议版本 v=DMARC1

p

必需 域的策略 p=quarantine

pct

可选 要过滤的邮件百分比 pct=20

rua

可选 汇总报告的报告 URI rua=mailto:aggrep@example.com

sp

可选 该域的子域的策略 sp=reject

aspf

可选 SPF 的匹配模式 aspf=r

有关其他可用标记,请参阅 DMARC 标记注册表

 

只有 v(版本)和 p(策略)标记是必需的。有三种策略设置(或邮件处置设置)可供选用:

  • – 不采取任何行动。仅在每日报告中记录受影响的邮件。
  • 隔离 – 将受影响的邮件标记为垃圾邮件。
  • 拒绝 – 在 SMTP 层撤销邮件。

匹配模式指发件人记录与 SPF 和 DKIM 签名相比的一致程度,有两个可能的值:宽松或严格,分别以“r”和“s”表示。简言之,“宽松”允许部分匹配(例如给定网域的子域),而“严格”要求完全匹配。

请务必在可选的 rua 标记中填入您的电子邮件地址,以接收每日报告。

下面是一些
DMARC TXT 记录示例 (_dmarc.your_domain.com IN
TXT),您略加修改即可使用。当然,要将“your_domain.com”和“postmaster@your_domain.com”替换为您的实际域名和电子邮件地址。

在以下 TXT 记录示例中,如果邮件声称从您的 domain.com 发送,但未能通过 DMARC 检查,系统将不采取操作。不过,所有这些邮件都会显示在发送到“postmaster@your_domain.com”的每日汇总报告中。

"v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com"在下面的 TXT 记录示例中,如果邮件声称从您的 domain.com 发送,但未能通过 DMARC 检查,那么以5%的比例将其隔离。然后,系统会将每日汇总报告通过电子邮件发送到“postmaster@your_domain.com”。

"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@your_domain.com"在最后这个示例中,如果邮件声称从“your_domain.com”发送,但未能通过
DMARC 检查,那么系统将 100%
拒绝该邮件。然后,系统会将每日汇总报告通过电子邮件发送到“postmaster@your_domain.com”和“dmarc@your_domain.com”。

"v=DMARC1; p=reject; rua=mailto:postmaster@your_domain.com, mailto:dmarc@your_domain.com"

每日报告采用
XML 格式。阅读该报告可以更好地了解邮件流情况。此外,报告还可以帮助您确保对出站邮件源进行正确的身份验证。如果不同 IP
地址发送声称来自您网域的邮件,请确保这些 IP 地址确实合法,并使用 DKIM 对其进行正确配置,或将其添加到相应的 SPF
范围内。如果新的邮件源上线但管理员设置了拦截策略,或者现有邮件源的配置出现问题,此时报告还可以帮助管理员快速采取措施。

下面是一份报告的摘录,显示了从两个 IP 地址发送的邮件的结果,一封邮件为直接发送,另一封为转发。两封邮件均成功发送:

 <record>
 <row>
 <source_ip>207.126.144.129</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record>
 <record>
 <row>
 <source_ip>207.126.144.131</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <reason>
 <type>forwarded</type>
 <comment></comment>
 </reason>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record> 

逐步部署

我们强烈建议您按照以下操作顺序应用策略,逐步增加 DMARC
的使用。首先,监控您的流量,并查找报告中的异常之处,例如仍没有签名或可能经过伪装的邮件。在您对结果感到满意之后,将 TXT
记录策略设置从“无”改为“隔离”。然后,再次查看结果,这次要检查垃圾邮件的捕获情况及每日 DMARC
报告。最后,在确信您的所有邮件都已签名之后,将策略设置改为“拒绝”,以充分利用 DMARC。重新查看报告,以确保结果如您所愿。

类似地,可选的
pct 标记也可以用来对 DMARC 进行分步部署和采样。因为默认值为 100%,所以,如果在 DMARC TXT
记录中采用“pct=20”,则系统只对所有受该策略影响的邮件中的五分之一(而不是全部)真正执行此操作。在您选择隔离和拒绝邮件时,此设置非常有用。在开始时设置一个较低的百分比,然后每隔几天逐步增加。

因此,比较慎重的完整部署过程应该像下面这样:

  1. 全部监控。
  2. 隔离 1%。
  3. 隔离 5%。
  4. 隔离 10%。
  5. 隔离 25%。
  6. 隔离 50%。
  7. 全部隔离。
  8. 拒绝 1%。
  9. 拒绝 5%。
  10. 拒绝 10%。
  11. 拒绝 25%。
  12. 拒绝 50%。
  13. 全部拒绝。

尝试尽快删除百分比,以完成整个部署。

请记得照常查看每日报告

Source: https://www.xiaoyu.net/1144.html