切换了 BizTalk 的数据库域,但无法删除 DC

切换了 BizTalk 的数据库域,但无法删除 DC

我继承了一个涉及 BizTalk(Server 2010)的旧系统,其中应用程序及其数据库位于不同域的不同服务器上。

人们一直在努力使系统和应用程序现代化,当数据库从 SQL Server 2008 升级到 2017 时,我必须随之而来。我认为,如果我们同时将数据库从其域移出以加入应用程序所在的同一域,则可以降低复杂性。由于它是域中的最后一个工件,因此我们也可以删除域控制器(理论上)。

数据库移动发生在生产中,它模拟旧版本,以便 BizTalk Server 2010 仍然可以访问它,并且应用程序可以运行 - 这让我很高兴。

但是,我们尝试删除数据库所在域的域控制器,然后应用程序失败,提示无法再与数据库进行身份验证。打开域控制器后,它又开始工作了。

我查看了我认为是 BizTalk 应用程序设置和 SSMS 中的数据库设置,但我不知道为什么仍然依赖于我们留下的域控制器。我必须假设,由于应用程序和数据库位于不同的域中,因此为了使其正常工作,域之间建立了某种形式的信任。

我对域控制器一无所知,也无法访问它们或它们的活动目录。我需要一些指导,并且尽可能在网上搜索了几次,但毫无收获。

我认为要么是我在数据库或应用程序端遗漏了某些问题,我仍然可以修复这些问题,要么是这些问题与一个或两个域控制器上的 AD 配置有关。如果是后者,那么我需要知道该向公司的 IT 团队询问什么问题,因为他们认为这是一个应用程序问题,如果没有具体细节,他们不会提供进一步的帮助。

公司希望我放弃旧的域控制器。有什么办法可以解决这个问题?

这个问题最初是在 Stack Overflow 上提出的(因为我是一名开发人员),但它不符合他们的指导方针,他们建议我在这里发帖。当时我收到了一个回复,一个乐于助人的人建议我通过搜索 BizTalk 管理数据库的所有表的文本来查找旧域名。我浏览了每一个,但没有在这里找到任何对旧域名的引用。希望这将有助于集中精力提供即将到来的帮助。

答案1

这不再适用,因为该公司决定放弃其解决方案并采用涉及不同技术的新解决方案。

在这种情况下,答案是让公司接受迁移到新版本的操作系统和中间件是一件好事,并将防止人们尝试使用不受支持的软件拼凑不受支持的服务器迁移并遇到问题。

我真诚地认为,尽管正确的 BizTalk 升级需要付出努力,但执行升级所需的时间仍将比创建新的解决方案所需的时间要短,并且他们将拥有为实现这一目标必须放弃的所有功能。

非常感谢大家的评论。

相关内容