标签: azure

它一直坐在“网关未创建”中。在 Azure 中创建虚拟网络后数小时。这是正常的吗？我该怎么办？

我们之前在错误的 DC 中创建了一个网络，当时它似乎没有那么慢。

使用 Microsoft Azure 我有一个默认的 Active Directory 域（显然）并且我可以创建 VM。令我惊讶的是，此类 VM 不会自动加入 AD 域，域用户无法登录。

是否可以将这些 Azure VM 加入 Azure 默认 AD？如何或为什么不？

谢谢！

我的印象是，一旦您加入域，本地管理员帐户就会被禁用。我在 Azure 中执行了以下操作：

1. 创建 Windows Server 2012 R2 实例并提升为域控制器。
2. 在 Windows Server 2012 数据库实例上创建 SQL Server 2012 SP1 并加入域。

在带有远程桌面 6.2.9200 (RDP Protcol 8.0) 的 Windows 7 机器上，如果不使用我创建的域管理员帐户，我无法 RDP 到我的机器。换句话说，我的印象是本地管理员帐户已被停用。

然而，在我的 Mac 上，使用应用商店中的 RDP 客户端，我能够使用本地管理员帐户登录，没有任何问题。我还注意到我可以从另一个 Win7 机器上的旧 RDP 客户端进行 RDP。

有任何想法吗？

我最近继承了与我合作的一家小型初创公司的基础设施职责。我的传统角色是发展，所以请耐心等待...

我希望从正确的角度开始，并在 Azure 中启动和运行 Active Directory。我已经按照 Microsoft 的 TechNet 上的指南在 Azure VPN 中安装 AD 林，我有以下结构

Azure VPN 配置为使用我的本地网络进行 Site-to-Site VPN，它显示为正确连接。

• 子网：192.168.5.0/24 HQNET
• 子网：192.169.1.0/24 站点到站点 VPN 网关
• 子网：192.169.2.0/24 认证
• 子网：192.169.3.0/24 应用
• 子网：192.169.4.0/24 数据
• 子网：192.169.6.0/24 中

我在 Auth 子网 IP 192.169.2.4 中的 A1 标准 VM 上有 Server 2012 R2。AD 安装进展顺利，开始了一个新的森林，一切似乎都运行良好。此 VM 是使用 Username1/Password1 创建的，在安装 AD 时会自动添加为域管理员/企业管理员。

我在同一个身份验证子网 - IP 192.169.2.5 中启动了第二个 Server 2012 R2 A1 标准 VM，用于复制目的，并使用 Username2/Password2 创建此 VM。然后，我将此 VM 加入使用第一个 DC 创建的域。加入域后，我尝试将此 VM 提升为副本 DC。它要求提供凭据来执行此操作，我提供 DOMAIN\Username1:Password1 作为凭据。

在提升过程 AD 到达在父 …

当我登录到新的 Azure 门户时，我会在右上角看到一个下拉菜单，让我可以从 2 的列表中选择一个“目录”。当我使用 powershell cmdlet“Login-AzureRmAccount”登录到 azure 时，我已连接到错误的目录。如何从 Powershell 中切换到另一个目录？

我有一个 Azure Web App，它有 15 个关联的域名（即所有域名都映射到同一个应用程序）。

我需要为所有 15 个域提供 SSL，指向同一个 Web 应用程序。

到目前为止我的观察：

• 传统的 SSL 绑定需要每个域一个 IP 地址，因此对于这个 Web 应用程序，我需要 15 个 IP 地址。

• Azure Web App 只为每个 Web 应用提供一个 IP，除非我以 39 美元/每个的价格购买额外的 IP。我想避免购买 15 个额外的 IP。

• 我可以在同一个应用服务计划下创建 15 个 Web 应用程序，但看起来它们都使用相同的外部 IP 地址，只要它们在同一个应用服务计划中，对吗？

• 较新的 SNI 绑定方案可用于跨多个域的单一 IP 地址，但在较旧的浏览器中不受支持，例如 WinXP 上的 IE（或多或少是 SNI 的唯一限制，我发现）

• 我想避免 SNI SSL 绑定，因为我们从无法支持 SNI 的 Windows XP/IE 用户那里获得了可观的收入。

鉴于我的要求：

• 在单个应用服务计划（单个或多个 Web 应用实例）上支持 15 个域名的 SSL
• 尽可能避免购买额外的 IP
• 尽可能避免 SNI

...在我看来，唯一合理的选择是 UCC/SAN SSL 证书，对吗？

如果是这样，当我尝试通过 Azure …

我设法更改了 Azure 门户的 UI 语言，但 Microsoft Azure 帐户站点没有相应更改。我在那里找不到直接更改它的选项。我是否忽略了什么？

我们正在与 Microsoft Azure 支持团队发生争执。我希望 Serverfault 社区能够加入，因为支持团队之前已经把我们搞砸了。

这是正在发生的事情。

作为我们在 Azure 上托管的更大 SaaS 服务的一部分，我们有一个前端应用服务，它接受基本的 HTTP 请求，执行一些小的验证，然后将繁重的工作传递给后端服务器。这个过程不是 CPU、内存或网络密集型的，我们根本不接触磁盘子系统。

定价层是“基本：2 中”，这对于我们施加的负载来说绰绰有余。CPU 和内存图表显示系统在很大程度上处于休眠状态，内存使用率约为 36%。

由于我们在服务器学校非常关注，我们使用 Azure 的标准监控设施积极监控整体解决方案的各个层。我们跟踪的计数器之一是“磁盘队列长度”，它是 Azure 应用服务上为数不多的可用计数器之一，因此它一定很重要。

回到服务器学校时，我们被告知理想情况下磁盘队列长度应为零，如果它持续高于 1，则您需要采取行动（某些 RAID 配置有一些例外）。在过去的几年里，一切都很好，磁盘队列长度在 99% 的时间里为零，在 Microsoft 为系统提供服务时偶尔会飙升到 5。

几个月前，事情开始突然发生变化（所以不是在我们推出更改之后）。磁盘队列警报开始泛滥，平均队列长度在 30 秒内。

我们让它运行几天，看看问题是否会消失（性能不会受到明显影响，至少在当前负载下不会）。由于问题没有消失，我们认为可能是底层系统有问题，因此我们实例化了一个全新的 Azure App Service 并迁移到该服务。同样的问题。

所以我们联系了 Azure 支持。自然地，他们要求我们运行一些无意义的测试，希望我们能离开（他们要求网络跟踪...磁盘队列问题！）。我们不会轻易放弃，所以我们运行了他们的无意义测试，最终被告知只需将队列长度的警报设置为 50（超过 10 分钟）。

虽然我们无法控制底层硬件、基础设施和系统配置，但这听起来并不正确。

他们的完整回复如下

我使用在此案例中收集的信息联系了我们的产品团队。

他们调查了您为磁盘队列长度指定的警报比预期更频繁地触发的问题。

此警报设置为在 5 分钟内磁盘队列长度平均值超过 10 时通知您。此指标是在采样间隔期间排队等待所选磁盘的读取和写入请求的平均数。对于 Azure 应用服务基础结构，此指标在以下文档链接中讨论：https : //docs.microsoft.com/en-us/azure/app-service-web/web-sites-monitor

对于部署的任何类型的应用程序，10 的值都非常低，因此您可能会看到误报。这意味着警报可能会比确切的连接数更频繁地触发。

例如，我们在每个虚拟机上运行反恶意软件服务以保护 Azure 应用服务基础结构。在这些时间里，您将看到已建立的连接，如果警报设置为较低的数字，则可以触发。

我们没有发现任何影响您网站可用性的反恶意软件扫描实例。Microsoft 建议您考虑将磁盘队列长度指标设置为 10 分钟内至少 50 的平均值。

我们相信这个值应该允许您为了性能目的继续监控您的应用程序。它也应该较少受到我们出于维护目的运行的反恶意软件扫描或其他连接的影响。

有人想插话吗？

我在 Azure 上的负载均衡器后面有 2 个 VM。我使用分配给负载均衡器的域，通过 Let's Encrypt 在其中一台虚拟机上创建了一个新的 SSL 证书。当我通过 IP 直接连接到该 VM 时，我看到已加载证书，但我现在无法将负载均衡器流量路由到 VM，该网站无法加载。

在我在 nginx 中添加证书和规则以将 80 重定向到 HTTPS 之前，一切正常。我在负载均衡器中添加了一条新规则，将数据从 443 路由到后台池 443，并为 443 添加了一个新的健康探测，但这并没有帮助。

我读到可以使用 Azure 应用程序网关直接在负载均衡器上加载证书，但在这种情况下，我需要重新创建我的 VM 以将它们放在同一个虚拟网络中，我想避免这种情况。

是否可以使用经典负载均衡器路由 HTTPS 流量。请注意，我可以将每个 VM 设置为使用相同的证书，以便在每个 VM 中获取 HTTPS 流量。

两周前，我们所有的 Azure 生产系统都宕机了，我们收到了一封来自他们的电子邮件，说

我们已禁用您的 Azure 订阅

为了保护您帐户的安全和隐私，我们会对所有 Azure 订阅进行例行审核。在其中一项审核中，我们发现了您订阅中违反 Microsoft 可接受使用政策的可疑活动。在问题得到解决之前，我们已禁用您的订阅。

如果您认为这是一个错误，请联系 Azure 支持。

我们知道没有问题，并且之前没有收到任何警告，因此我们联系了支持人员。（我们有一个标准支持计划，可以让我们得到相当快的响应，但不一定是解决方案。） 11 小时（和许多电子邮件）后，一切又重新启动，我们收到一条消息，简单地说

您的订阅已启用。

Microsoft 没有回答有关此“可疑活动”是什么的解释的询问，也没有回答他们如何解决这种情况并能够再次启用我们的帐户。他们没有解释为什么他们不能在问题持续时间内提供有关问题原因的信息。

有没有其他人经历过这种情况？未来我们如何避免呢？

编辑

微软现在已经回应并表示

...我们发现可疑活动发生在最初映射到您订阅中部署的服务的 IP 上。IP 托管了一个归因于 Azure 的网络钓鱼页面。因此，我们的系统会跟踪订阅并标记为违反使用条款。因此订阅被暂停。

他们也承认花费的时间比应有的要长。他们给了我们一个月使用该订阅的信用。