这可能是“如果我更新了它的名字，我可以在 5 分钟内用谷歌搜索它”的情况——但我不知道它叫什么。
最好用一个例子来解释这个要求。我们从我们的一个数据中心托管了许多服务（vpn、owa 等）。我们有许多数据中心，从技术上讲，我们已经在许多数据中心拥有支持这些服务的基础设施。为了提供对这些“服务”的访问，我将创建一个外部 DNS 条目（例如 VPN.MyCompany.com > 我的一个 DC 的网关 IP），客户端将通过 DNS 条目连接到它。由于我有多个可以支持此服务的数据中心，如果我可以将此 DNS 条目指向某种提供高度可用“重定向”服务的第三方，我理论上可以提供“高度可用、地理上分散”的解决方案。如果我的主站点出现故障，我可以通过一些管理控制台进行更改并将重定向器配置为指向不同的 DC。当然，在我们的一台服务器上设置这种东西是相当简单的，但这会有点违背高可用性第三方的目的。
有人熟悉这样的服务吗？我正在考虑类似 DynDNS，但具有企业可用性保证。
我正在尝试跟踪我们环境中的 SharePoint 采用情况。不寻找像“我们的用户访问 SharePoint 的范围有多大”这样复杂的东西 - 只是“每个月有多少不同的用户登录 SharePoint。所有用户都通过 Windows 身份验证登录。
有任何想法吗？
这可能是一个可笑的简单问题，但这里......
我正在解决一个问题，即应用程序（SQL Server Analysis Services）一次在 30 到 60 秒之间不可用，每天多次。我已经在应用程序服务器上本地运行了监控，并验证了服务在任何时候都没有关闭，这让我怀疑是网络问题 - 连接断开或网络泛滥。
问题是，我不知道如何持续监控两台服务器之间的网络连接。我是一名 DBA - 这不是我的特色 ;-)
正如我所说，“停机时间”非常短暂，所以当我收到警报时，我没有机会 ping AS 服务器。我可以运行一些东西来监控两个盒子之间的连接（可能是往返时间）吗？
我集群的一个 SAN 上的控制器会定期自行重启。显然它可以通过固件更新来修复，但在我们可以在几天内应用更新之前，我必须忍受这个问题。问题是，如果其中一个在 DBCC CHECKDB 运行时发生故障（在夜间维护期间），则 CHECKDB 会挂起。我似乎无法杀死它......它表明它正在等待 ASYNC_IO_COMPLETION 永远。我需要循环实例，还是有其他方法可以杀死 CHECKDB？
SQL Server 2005 RTM & SP2 实例。
我们的 Exchange 服务器每天收到 450,000 到 700,000 封垃圾邮件。我们在同一时间范围内收到大约 1700 条合法消息。
大约 75% 的垃圾邮件是目录收集。我们目前安装了 GFI MailEssentials。值得称赞的是，它做得非常好，但是我们收到的垃圾邮件的绝对数量，以及我们的交换服务器正在建立的连接数量正在阻止及时发送合法电子邮件。
GFI 设置为在 SMTP 级别检查目录收集，我认为它会在邮件到达 Exchange 服务或通过 SMSE 之前拦截邮件。这个“模块”排在列表的顶部，因此（希望）处理收获会消耗最少的服务器资源和带宽。
我的问题是，我能做些什么来防止我们的 Exchange 服务器的连接池被这些垃圾邮件主机吃掉吗？我们不得不限制 Exchange 建立的并发连接数，因为它占用了我们所有的带宽。
提前致谢。