多年没写过批处理了，来新公司的第一个case却是需要写一个bat脚本，批量更新采集agent的配置文件，其中就涉及到远程IP的端口检测。

　　确实可以使用，不过检测速度不敢恭维，通与不通都很慢！鉴于手头没有更好的解决办法，就先试试看，贴一下我写的Portqry相关demo：

　　于是兴冲冲的封装成exe，给IDC（server2003系统）执行，结果第一台就悲剧了！远程桌面直接断开了：

　　然后再也连不上了改变ip地址代理服务器，要他们去机房看了下，结果告诉我系统没了！！？？太震精了有木有？一个简单的文本操作脚本，居然把系统干掉了么？而且脚本中都不存在任何删除命令。。。

　　既然工具不敢用了，还是继续折腾代码吧！周末睡觉前突然灵感一闪，想起了tasklist判断窗口名称这个“失传绝技”，于是把刚关闭的本子又打开，终于在GF的不断抱怨之下搞定了这个问题。

　　思路比较简单：使用start命令在新窗口执行telnet -e 和 exit命令，如果端口畅通，那么新开的窗口将会立即关闭，而不通的窗口则会保持近半分钟左右，且窗口名称类似 telnet 192.168.1.1，这半分钟时间足够脚本来判断通还是不通了。

　　这样就解决了Windows下telnet探测远程端口的问题了，而且检测速度比微软哪个portqry快多了，果然思路比技术更重要，只要有想法，任何技术都不应该成为瓶颈！

　　当使用窗口判断的方案下发各大机房实施的时候，又一个问题出现了！窗口判断在某些版本的Windows下是行不通的，比如英文版下的命令提示符窗口名称和中文版的就不一样，所以这个方案也是不完善的！

　　c. 延迟几秒后统计系统中存在的telnet.exe进程数（存在的telnet表示是不通的）

　　很明显，这样就可以知道我测试了所有IP当中有几个是不通的了。遗憾的是无法知道是哪个IP不通。不过在手头的这个case当中是不需要具体不通的IP的，只要知道通的IP是否达标就行。

　　好了，终于把这个问题给解决了。显然，任何时候都需要给出多个方案，而不是自满于一个方案。否则出问题就会焦头烂额了。当然，再次说明了想法比技术更重要。