Tuesday, January 19th, 2010 at 8:28 pm
the remote computer disconnected the session because of an error in the licensing protocol. please try connecting to the remote computer again or contact your server administrator.
来源:http://support.microsoft.com/kb/187614/zh-cn
如果某个未经授权的客户端首次连接到终端服务器,终端服务器将向该客户端发出一个临时的终端服务器客户端访问许可证 (CAL) 令牌。用户登录到会话后,终端服务器指示许可证服务器将发出的临时终端服务器 CAL 令牌标记为已验证。在客户端下一次连接时,系统会尝试将已验证的临时终端服务器 CAL 令牌升级为完全终端服务器 CAL 令牌。如果没有许可证令牌可用,则临时终端服务器 CAL 令牌将继续工作 90 天。该许可证存储在客户端的注册表中。
32 位 RDP 客户端将其许可证存储在 HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing 项下。
重要说明:此部分、方法或任务包含有关如何修改注册表的步骤。但是,注册表修改不当可能会出现严重问题。因此,请一定严格按照下列步骤操作。为了获得进一步保护,请在修改注册表之前对其进行备份。这样就可以在出现问题时还原注册表。有关如何备份和还原注册表的更多信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
322756 (http://support.microsoft.com/kb/322756/ ) 如何在 Windows 中备份和还原注册表
要清理客户端的许可证缓存,只需删除此项及其子项。在客户端下一次连接到服务器时,它将获得另一个许可证。
对于 16 位 RDP 客户端,请运行 regedit /v。然后删除“\Software\Microsoft\MSLicensing”下的项以清理客户端的许可证缓存。还可以删除 \Windows\System\Regdata 中的 BIN 文件。
Macintosh RDP 客户端将许可证存储在本地计算机上 /users/Shared/Microsoft/RDC Crucial Server Information/ 下的文件夹层次结构中的一个文件内。要清理 Macintosh 客户端的许可证缓存,请删除此文件夹中的内容。客户端将在下一次连接时尝试从服务器获得新许可证。
如果删除运行 Windows Vista 或更高版本的客户端上的 HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing 子项,则以后连接终端服务器的尝试可能会失败。并且,您会收到以下错误消息:
An Error occurred in the Licensing Protocol
要解决此问题,请右键单击“远程桌面连接”快捷方式,然后单击“以管理员身份运行”。默认情况下,远程桌面连接以具有最低用户权限的用户身份运行。默认情况下,受限用户不具有向 HKEY_LOCAL_MACHINE 写入注册表项的权限。因此,重写 MSLicensing 项的尝试失败。使用管理凭据启动“远程桌面连接”可提供写入所需注册表项所必需的权限。
后记:
这个东西一直困扰我好久,因为自己不用windows,而在linux下面,可以直接用-n newname来解决,所以就一直隔这里了。这几天被同事一直催着解决这个问题,没办法,这下仔细研究了一下。
看样子,选中关键词很重要啊。。。。
Monday, October 19th, 2009 at 8:56 pm
今天早上在上课的时候,有同事跟我说他怎么就是不能重新安排grub,我问他报什么错误,他就是不说,然后我就只好自己测试了。果然,在进入rescue模式之后,一旦用grub-install来安装grub,只是提示这个错误:
No suitable drive was found in the generated device map
一查看/boot/grub/device.map,发现上面居然只有一行:
居然连硬盘都没有添加上去,当然安装不成功了。。。
于是,在这个文件里面加上
然后再运行grub-install,果然就可以安装了。
PS:最后还有一个小问题,在grub.conf配置与fstab配置正确的情况下,系统启动还是报kernel panic,最后重装了内核才搞定。估计这位仁兄是在安装grub之前就装了内核,结果还是device map不正确导致的问题
Wednesday, September 30th, 2009 at 2:28 pm
最近不知道为什么,我x200总是会出现无线崩溃的情况。就算你用下面这条命令,得到的居然是设备忙…
$ sudo iwlist can
lo Interface doesn't support scanning.
eth0 Interface doesn't support scanning.
pan0 Interface doesn't support scanning.
wmaster0 Interface doesn't support scanning.
wlan0 Interface doesn't support scanning : Device or resource busy
没办法,只好试着把驱动删除,然后再重新加载
用下面命令删除相关的无线模块:
# modprobe -r iwlagn
# modprobe -r iwlcore
# modprobe -r mac80211
用下面命令重新加载无线模块
# modprobe mac80211
# modprobe iwlcore
# modprobe iwlagn
根据无线网卡型号的不同,上述模块名应该会有不同,附上我的无线网卡型号做参考
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5300
Monday, June 15th, 2009 at 3:42 pm
今天监控脚本发现从库突然停了,又报了以下错误:
Last_Error: Error 'There is no 'user'@'192.168.0.234' registered' on query. Default database: 'testdb'. Query: 'INSERT INTO testtablle(userId,uesrName) VALUES (128,'user')'
很奇怪的错误,后来一问,原来是DBA在更新库的时候用了自己的帐号,而在从库上没有给他设置相应的帐号,这才导致从库同步失败,建立一个拥有相同权限的用户,然后重启一下slave就可以了
Friday, June 5th, 2009 at 8:23 pm
今天同事的机器因为一个误操作删除了一个不应该删除的东西,把声卡给搞没了,后来要装的时候,却再也装不上了。
在硬件设备管理器中,总是会一个未知的PCI设备。
查了相关的资料,总算微软的tecknet上找到了答案:
http://social.technet.microsoft.com/forums/en-US/itproxpsp/thread/dd309773-6bb6-4311-8d9f-28d848bca4f8/
原来,那个同事删除的是是KB888111升级包的相关部分,只需要将这部分重装一次就可以了。但由于我们的机器都已经安装了SP3,这个包已经不能直接重装,只能通过这样子来了:
- 将用KB888111XPSP2.exe用winrar解压到指定目录,比如C:\KB888111XPSP2
- 打开设备管理器,并找到那个未知的PCI设备(有黄色叹号的)
- 右击未知的PCI设备,然后选择更新驱动的那个选项
- 将搜索驱动的路径设置为C:\KB888111XPSP2\commonfiles\
- 如果还是继续得到未知设置,可尝试重复第2-4个步骤,也可重新安装原来的驱动
果然,通过这几个步骤,他的声卡可以继续使用了。
点击下载:kb888111xpsp2
myhnet
M$ & Window$, troubleshooting
asus, KB888111, KB888111XPSP2.exe, p5l-mx, PCI device, Realtek, SP3, 华硕, 声卡, 声卡驱动
Thursday, June 4th, 2009 at 8:28 pm
最近碰到一个很奇怪的问题,两台一模一样的机器,一样的时间,一样的时区,一样的tomcat,一样的代码。但是tomcat在两台机器上获取到的时间就是不一样,不仅不一样,其中一个的tomcat时间跟系统时间还不一致。
最开始试着通过修改catalina.sh把两个tomcat的时区都改为GMT,结果得到的时间还是不一样:
JAVA_OPTS="-mx1600M -Duser.timezone=GMT"
后来把tomcat的时区改为:
JAVA_OPTS="-mx1600M -Duser.timezone=Europe/London"
突然发现这个时候这台tomcat时间与系统时间一向不一致的机器,这个时候tomcat时间突然跟系统时间一致了,而另一台一直直一致的现在却不一致了(系统用的时区是BST,开始改GMT时区时没看出来)。
这个时候我才突然想到,tomcat读取的可能是硬件时间(BIOS时间),而这两台机器很有可能一台设置了使用UTC时间一台设置了不使用UTC时间。遂查看配置文件/etc/sysconfig/clock,果然如此。
修改成一致的设置,重启,果然正常了。
Thursday, April 16th, 2009 at 8:43 pm
今天碰到了一个很奇怪的问题,好好的,我在一个CentOS下面居然改不了时区。
先是直接按老办法修改/etc/localtime,结果没用,接着,又修改/etc/sysconfig/clock文件,还是没用。
接着用system-config-time命令进行修改,居然都没有用。。。
怀疑缓存问题(我居然会想到这个,蠢透了),重启机器,还是没用。。。
后来想起来一个专门调节时区的命令:tzselect,试了试,依然没有用。
不过,突然发现有这么一行信息:
You can make this change permanent for yourself by appending the line
TZ='Europe/Mariehamn'; export TZ
to the file '.profile' in your home directory; then log out and log in again.
在想,会不会是TZ这个变量在做怪,重新登陆了系统,发现这台机器上的TZ变量居然已经设置好了,对比正确的机器,这个值应该是空的。于是,清空了这个值,前面的修改就可以生效了。
最后检查了一下原因,不知道什么时候有人添加了这个文件:
将这个文件删除,一切都OK!
Sunday, March 8th, 2009 at 4:04 pm
上课的时候给学生留了个作业,让学生用xinetd来配置sshd,结果我自己没有搞定,太丢了。。。
按理说,sshd进程运行的时候,是不需要参数的,但是配置到xinetd之后,就是只能监听端口不能登陆系统。每次登陆,都会报如果错误:
ssh_exchange_identification: read: Connection reset by peer
如果加上-v参数查看的话,就会有这么一个报告:
debug1: ssh_exchange_identification: sshd re-exec requires execution with an absolute path
查到最后,后来是sshd如果用于inetd(xinetd)模式的时候,需要加上一个参数-i。
因为在inetd(xinetd)模式下,sshd在响应客户端之前要花上大约十秒的时候来重新生成一个服务器端的key,客户端不会花那么长的时间等待,所以就会报错。
而且,这个参数只用于inetd(xinetd)模式。
附正确的配置文件:
service ssh
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/sshd
server_args = -i
disable = no
}