本文主要是介绍诡异的windows Workspace 2276,2269报错解决,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
背景信息,使用了windows server 2012 上的文件服务,文件服务器是cluster (两个节点),而且开启了windows sync share 的服务。但是在节点2上的windows sync share 服务一直不能启动,日志里报2276,2269错误。
第一次解决,我是把node2上的iis组件全部卸载了,然后按照node1上的组件进行安装,问题解决后,我还配置了workspace 服务的群集设置。
最近两次发现均有切换服务到node2 时出现windows sync share 服务无法启动的问题,找了很多文章和链接,没有用处,只能通过上面重新安装的方式解决,5月8号又遇到该问题。
报错时发现仍然是工作组进程未能初始化的日志,还总结出下面现象和信息:
- Workspace 使用的是hostablecore ,http.sys 底层的功能,不依赖iis ,但是使用IIS 管理器发现www 服务是启动的。手动启动node2上的windows sync share 服务报-2147024713,和该文章中的现象类似,但又不一样,该文章中有IIS站点,但我们的环境中没有,且node1即使开了www服务也正常,node2开了www就不正常
- node2 上的windows sync share 服务不能启动。停止www 服务后,node2 上的windows sync share 服务可以启动。停止node1上的www 服务对workspace 没有影响。所以结论是www服务似乎对workspace 服务无影响,但是对windows sysnc share 服务可能造成冲突。(但是fsnode1,fsnode2上表现不一致让人很困惑).
最终解决办法:
1.禁用文件服务器群集每台上的www服务,www 服务禁用后windows sync share 可在node2上启动,对node1也没有影响。
最后的疑问:
node1,node2配置一样,为什么node1上www服务和windows sync share 服务就不冲突,而node2上就冲突….
转载于:https://blog.51cto.com/yoke88/2391480
这篇关于诡异的windows Workspace 2276,2269报错解决的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!