小编Sco*_*ott的帖子

我们最近购买了一台运行 Hyper-V 2008 R2 裸机的服务器。该服务器有两个带超线程的四核 Intel Xeon 处理器，所以如果我理解正确的话，这给了我们 16 个内核。在 Hyper-V 中，我们创建了一个运行 Windows Server 2008 R2 的虚拟机，带有 4 个虚拟处理器。处理器设置屏幕告诉我，这代表了系统总处理能力的 25%。这是否意味着剩余的 75% 不能被虚拟操作系统利用？我们将运行其他一些虚拟机，但这是用于 SQL Server 的，我们希望尽可能多地使用它。

我们正在更换我们的 SQL Server，并决定重命名服务器本身比更改其他所有内容以指向新名称要容易得多。我们找到了有关更改 SQL Server 实例名称以匹配计算机名称的说明，如下所示：

sp_dropserver 'OLDSERVER'
sp_addserver 'NEWSERVER', local

尽管 SQL 企业管理器似乎不喜欢这些在一起。我必须将其更改为以下内容才能使其协同工作：

sp_dropserver 'OLDSERVER'; GO
sp_addserver 'NEWSERVER', 'local'; GO

这还不错，但我更喜欢自动化程度更高的事情。由于@@ServerName 返回实例的名称，我想出了如何自动化第一行：

sp_dropserver @@ServerName; GO

我还了解到 SERVERPROPERTY('ServerName') 应该返回计算机名称，所以我想我可以用它来自动化第二部分，但这不起作用：

sp_addserver SERVERPROPERTY('ServerName'), 'local'; GO

我尝试设置一个变量，无论如何我都需要这样做来更新 SQL 代理作业，但这也不起作用：

DECLARE @srv sysname;
SET @srv = CAST(SERVERPROPERTY('ServerName') AS sysname);
sp_addserver @srv, 'local'; GO

“sp_addserver”附近的语法不正确。

我非常希望不必将新服务器名称硬编码到脚本中，以使其更易于重用。有人有任何想法吗？

这应该是社区维基。我正在尝试列出我们应该定期执行的所有系统管理员任务的列表，因为我相信我们在公司做得还不够。这里的态度是修复问题不方便，但我们没有时间做预防性维护或持续改进。

日常的：

• 更换每晚备份磁带/驱动器
• 检查防病毒更新是否已推送到所有系统

每周：

• 每周更换备份磁带/驱动器
• 清除所有系统中的临时文件
• 对所有系统进行碎片整理

每月：

• 规划基础设施改进
• 将过时的设备交付/发送给电子产品回收商
• 重建或更换老化的工作站
• 测试从备份恢复

年度的：

• 重建或更换老化的服务器
• 更换 UPS 电池

作为定期预防性维护的一部分，我们会检查网络中工作站上的事件日志是否存在严重问题（例如，diskperf 错误）。一些工作站通常有一个严重错误，解释是“故障桶”后跟一些数字。谁能解释一下这是什么意思？它真的指向我们应该关心的一些关键问题吗？我们能做些什么让它不再出现？

如果我每天在使用 SQL Server express 的站点上有 50k 次点击，这是一个问题吗？

安排备份和其他任务有多容易？我知道这一切都是可行的，但这更痛苦吗？

编辑：我还想补充一点，我将为多个网站使用相同的安装。

我希望在一个两人 IT 部门实施 ITSM。我们有一个基于 Web 的工作流系统，其中定义了五种请求类型，这些请求类型最终会出现在我们部门。请求类型划分背后的基本原理是为了分类，但用户通常不了解选择哪种请求类型。

我计划通过仅向用户显示一种请求类型来简化系统，然后我们将在必要时更改类型。但与其按技术领域分开（当前的请求类型是计算机支持、Web 支持、ERP 支持、CRM 支持和分析师支持），我认为最好将其分为事件、问题、变更请求和服务请求。旧的分类方式将被替换为将每个请求链接到代表相关服务的项目，这将由我们而不是用户来完成。

现在，我们的工作流系统将分配给您的所有请求显示在一个巨大的列表中。可以自定义显示的字段，以便您可以查看哪些是事件与更改请求。我一直在考虑编写自己的前端，以在屏幕上的单独分组中列出每种请求类型。这让我想知道请求的优先级。每个请求都分配了 1 到 5 之间的优先级，因此优先级 1 变更请求比优先级 3 变更请求更重要。但是，优先级 2 的事件是否比优先级 1 的变更请求更重要，因为它是一个事件？因为部门里只有我们两个人，所以我认为我们无法在事件发生时处理变更请求。一世' 一直认为你应该在构建任何新东西之前修复损坏的东西。还是我出去吃午饭？我们是否应该忽略请求类型并仅根据优先级进行工​​作？

如果我正朝着正确的道路前进，优先考虑所有事件，那么我应该如何优先考虑其他请求类型？我最初的倾向是接下来做服务请求，因为我希望它们很快，然后是变更请求，最后是问题。但是，我有点担心将问题放在最后，他们将永远不会被调查。也许订单应该是事件、服务请求、问题、变更请求？

我们正在更换服务器机房的搁架，我找到了一张纸，上面列出了停电期间/停电后要采取的各种措施：

1. ADSL 调制解调器电源关闭和打开
2. 启动所有服务器
3. 启动生产订单轮询流程
4. 检查：电子邮件服务已启动
5. 检查：SQL 代理服务已启动
6. 检查：Internet 连接已恢复
7. 复印机：关机再开机

其中一些步骤是有道理的，但我不确定是否会断电。我们所有的调制解调器、路由器、交换机和服务器都使用备用电池。PowerChute Business Edition 安装在服务器上，并且它们被配置为在最后一分钟自动关闭（因为我们会遇到很多短暂的中断）。我从过去的停电中知道自动关闭正在工作，并且当电源恢复时服务器会再次自动开机。复印机没有备用电池，考虑到每个人都希望它们死掉，我对保护它们并不真正感兴趣。

检查事情是否再次启动并运行是有意义的，我已经配置了相当多的自动电子邮件来处理这个问题（使用第三方监控服务）。

那么在停电期间我真的需要做什么？我认为记下时间并致电电力公司就足够了。我在本网站的其他地方读到有人建议手动关闭所有设备，但我们不会在电源恢复之前留在现场，因此我们更喜欢让事情自行恢复。

为了提供有关环境的一些背景信息，我们的电子邮件服务器以及运行我们的在线订购系统和邮编定位服务的网络服务器都位于内部。这些需要上升，尽管当我们下降时订单并没有真正丢失；我们是一家拥有分销网络的制造公司，因此我们不直接向最终消费者销售产品。当系统恢复时，我们的经销商将输入他们的订单。

自从从标准时间切换到夏令时，我们的电子邮件信息的时间已经提前了一个小时。这个症状让我想知道原因是否是夏令时设置的不正确配置。

由于我们处于客户端/服务器环境中，客户端与服务器同步，服务器与科罗拉多州博尔德同步。如果我将服务器和客户端都设置为自动切换到夏令时，则客户端似乎将服务器设置为标准时间并将自己设置为提前一个小时，这实际上是提前了两个小时。服务器应该切换到夏令时并且客户端继续进行下一次同步，还是应该服务器保持标准时间并且客户端切换？

Exchange Server 上的系统时钟当前显示正确的时间。如何让电子邮件在 Outlook 中显示正确的时间？