学无止境

一直觉得 Hyper-V 作为 Windows 自带的虚拟机系统，其性能应该比 VirualBox 或者 VMware 高一些吧？然而，实际用起来，真没觉得性能有多高，甚至觉得性能很差。也许是因为我的虚拟机文件都建在外置的 USB 硬盘的原因？USB 3.0 也不管用？最近又在 Hyper-V 里新建了一个 Debian 的系统，发现通过默认的方式连接桌面，其 UI 及其卡顿。。。本想干脆试试 VMware 吧，谁知 VMware 和 Hyper-V 好像势不两立，不能共存，而且终究商业软件，要想用好，就得付费，于是暂时放弃。可能 Hyper-V 的默认应用场景里，用它自带的工具访问桌面，更多的属于最后手段，并非预设让你一直靠它访问其内的桌面。然后发现可以在 Linux 里安装 xrdp，这样就可以通过 Windows 远程桌面访问，而且支持 Host 和 Guest 系统的粘贴板互通。于是打算尝试一下，看看能否解决访问桌面卡顿的问题。

要安装 xrdp 很简单，还是靠老朋友 apt-get:

1

sudo apt-get install xrdp

安装完毕之后，尝试使用 Windows 远程桌面去连接 Debian，第一步很顺利，显示出了 xrdp 的界面，其中需要选择 “Session” 的类型，如果 Linux 系统里安装了某种 vnc, 可以选择 vnc，而我的 Debian 系统里没装 vnc，所以默认 Xorg 即可。下面是输入 Debian 中的用户名和密码。全部输入完成之后，点 “OK” 按钮，却报了一个错误。

搜索 xrdp 的错误信息之后，得到几个解决方法，都尝试了一下，也不知道具体是哪个或者组合起来，最终解决了问题。首先，卸载掉 xserver-xorg-legacy:

1

sudo apt-get purge xserver-xorg-legacy

其次，修改或者创建以下文件：/etc/X11/Xwrapper.config，其中添加或修改以下内容：

1

allowed_users = anybody

经过上面的步骤，再次尝试连接，连接成功，UI 速度很快！

平常用 Windows 远程桌面访问服务器的时候总是会遇到证书警告，像这样：

这是因为服务器上的远程桌面连接用的证书通常是服务器自己给自己颁发的，根本不受 Windows 信任。而我手头已经有了来自认证机构的受 Windows 信任的域名证书并且已经添加到了服务器上，所以如果我可以让服务器使用那个证书来建立远程桌面连接，那么就可以消除那个证书警告，确保整个连接是可靠的。

经过一顿搜索，终于在 Serverfault 找到了正确的处理方法，并且实践成功。

现在把步骤列在这里备忘。以下步骤是在 Windows Server 2016 上实践的。

1. 将服务器的名字改为证书关联的域名。比如你的证书可以关联到 myserver.abc.com，那么就把服务器的名字改为 myserver.abc.com，更改方法如下图：

   

2. 安装域名证书到服务器。注意要安装到 Computer Account，不要安装到 User Account。然后安装到 Personal 分类下。

3. 得到证书指纹。从此步骤开始，所有操作都是 Powershell 命令，运行于 Administrator 权限下的 Powershell 环境。

   Get-ChildItem "Cert:\LocalMachine\My"

   把证书的 Thumbprint 值复制下来，后面要用到。

4. 设置一个变量保存 “RD Session Host RDP listener” 的 WMI 路径

   $PATH = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices)

5. 最后一步，更改 RDP listener 的证书设置

   Set-WmiInstance -Path $PATH -argument @{SSLCertificateSHA1Hash="thumbprint"}，其中， thumbprint 就是在第3步中得到的值。

大功告成！

RDLC 支持的导出格式有：Excel, EXCELOPENXML, IMAGE, PDF, WORD, WORDOPENXML

之前在群里灌水提起 Visual Studio 2017 现在会在你写代码的时候根据类型名称“推荐”变量名称，类似这样：

然后有人说某某插件在很久之前就支持这种操作了；有人又赞美太阳——哦，不——赞美微软了；也有人问“但是怎样才能让 VS 建议以下划线开头的变量名呢？”。 这是个好问题，并且 Visual Studio 2017 确实可以做到。

前段时间公司的开发服务器从内部服务器转移到了一台公网的 Azure 服务器，SQL Server 也变成公网开放，因此其面临的安全性风险骤增。为了提升安全性，数据库用户现在没有 Sys Admin 权限，仅有权访问少数数据库。这带来一个问题就是数据库重启以后，TempDB 数据库被重建，非 Sys Admin 角色的数据库用户就失去了操作 TempDB 的权限，进而导致一些需要 TempDB 数据库操作的操作失败。

解决的问题有两种，一种就是将数据库用户添加到 Model 数据库，因为所有新建数据库都是复制自 Model 数据库，因此重建 TempDB 数据库就自带了需要的数据库用户。这种做法的缺点也很明显，任何新建数据库都默认自带那些数据库用户，这可能并不是我们期望的。第二种方法是我们设立一个自动任务，每次 TempDB 数据库重建，我们就自动给它添加上需要的数据库用户。这里我们介绍一下如何实现第二种方法。

我们假设为登录用户 abc 在 TempDB 数据库中创建对应用户并赋予它 TempDB 数据库的 db_owner 角色。代码如下：

1
2
3

use TempDB
create user abc from login abc
exec sp_addrolemember 'db_owner', abc

接下来，我们利用 SQL Server Agent 设立一个自动任务来运行上面的脚本，Schedule Type 选为”Start automatically when SQL Server Agent starts”即可。