简介针对Teamcenter AWC2406部署中的常见问题这份docx笔记整理了从环境准备、依赖服务安装到Deployment Center配置、组件设置及生成部署脚本的完整操作流程适合负责TC实施或维护的工程师按图索骥减少因主机名、网络或组件配置错误导致的中途返工。资源仅1个文件格式为docx共4.67MB内容以分步说明配以路径提示为主重点提醒修改主机名、关闭防火墙与IPv6并完整给出JDK17.0.3、Siemens License Server、SQL Server 2019等前置安装要求随后通过Deployment Center介质添加、环境创建、应用程序与组件逐项配置覆盖Active Workspace Client、Gateway、Corporate Server及Database Server等关键模块同时强调数据库与TC密码禁用特殊符号等易忽略细节。目前已获得312人学习尤其适合首次部署AWC2406、希望系统掌握安装全流程的工程师。借助其中日志排错思路、deploy.bat参数示例与运行命令可快速定位添加介质失败等问题显著提升安装成功率。1. Teamcenter Deployment Center 装 AWC2406先把这条链跑顺再动手AWC2406 的安装难的不是点下一步而是十几个组件之间的依赖关系。手动逐个装 Active Workspace Client、Gateway、Corporate Server、Indexer 这些服务任何一步端口冲突或密码解析出错都要花半天时间排查。用 Teamcenter Deployment Center 2406 可以把「介质入库 → 环境建模 → 组件配置 → 脚本生成 → 一键部署」串成一条可控的链路这也是当前 Teamcenter 环境安装 AWC 的主流方式。这篇文章面向刚接手 Teamcenter 环境、需要在干净服务器上从零部署 AWC2406 的运维和实施工程师按实际操作顺序拆解安装准备、介质入库、组件配置到 deploy.bat 落地的全过程并把我在现场踩过的坑一并写出来。2. 装前准备三件事主机名、网络策略与 JDK/License/数据库顺序2.1 修改主机名与 hosts 映射影响的是许可校验和 URL 生成很多安装教程会用黑色笔记把截图里的主机名盖住提示你改成自己的主机名。这一步看上去无关痛痒实际上它决定了后面 License Server 的许可校验、Active Workspace Gateway 生成的访问 URL、以及部署脚本里所有服务地址的正确性。如果装机时主机名没改到了部署阶段才发现问题改完主机名后 Deploymen Center 生成的脚本里还残留旧主机名只能重新生成环境非常被动。主机名的规范建议用小写字母加数字比如 TcSrv01避免下划线和过长名称。修改完系统主机名后还要在 hosts 文件里补一条主机名到本机回环地址的映射防止许可服务做主机名反查时去请求不存在的 DNS。:: 1) 管理员身份打开记事本编辑 hosts 文件 notepad C:\Windows\System32\drivers\etc\hosts :: 2) 在文件末尾追加一行把主机名解析到本机 127.0.0.1 TcSrv01这里把 127.0.0.1 和主机名之间用 Tab 分隔不要用空格。加这一行的原因是 Teamcenter 的 License Server 在校验许可时会做主机名解析如果 hosts 里没有对应记录服务启动会变慢甚至直接失败。你有内部 DNS 也可以不写但多数实施环境的主机名解析不可控这种本地映射是最稳妥的做法。改完 hosts 之后用hostname命令确认一下当前系统主机名输出结果要和 hosts 里追加的名字一致。如果不一致说明系统主机名还没改成功要重新设置并重启。这一步先做对后面生成安装脚本时 hostname 才会以正确值写入所有配置文件。2.2 关闭防火墙与禁用 IPv6减少网络层变量的干扰Deployment Center 在部署阶段会启动很多服务组件之间的通信端口非常多像 Corporate Server、Microservice Node、Indexing Engine 各自监听不同端口。如果开着 Windows 防火墙每漏一条放行规则部署过程就会在某一步突然失败而且日志不一定直接提示防火墙拦截。所以我一般在内网部署机上先把防火墙全部关闭等整套环境装完、验证通过之后再按实际端口列表把防火墙策略收紧到最小范围。:: 关闭 Windows 防火墙的三个配置文件域、专用、公用 netsh advfirewall set allprofiles state off :: 禁用 IPv6 协议 netsh int ipv6 set state disabled第一条命令把域、专用、公用三种网络配置文件的防火墙统一关闭避免后续服务绑定端口时被拦截。第二条禁用 IPv6 的原因比较玄学在 Windows Server 双栈环境下SQL Server 和 Teamcenter 之间的 TCP 连接有时会解析到 IPv6 地址导致连接超时或报网络不可达而服务本身配置的却是 IPv4 地址。把 IPv6 直接禁掉能让所有连接串老老实实走 IPv4 路径。这个改动重启服务器后完全生效因此建议在安装 JDK 之前就把它设置好。需要留意的是禁用 IPv6 后要确认服务器的物理网卡配置没有强制依赖 IPv6 协议否则重启后可能出现网络异常。对于一台干净的部署机来说这个风险一般是可控的。2.3 JDK 17.0.3、Siemens License Server 与 SQL Server 2019 的安装顺序安装顺序建议是JDK 17.0.3 → Siemens License Server → SQL Server 2019。JDK 必须放在最前面因为 Deployment Center 的 repotool 和后面 Indexing Engine 组件都依赖 Java 运行时JDK 版本不对介质入库时日志会直接报 UnsupportedClassVersionError。JDK 版本尽量用 17.0.3这是 AWC2406 构建基线验证过的版本用更新的 17.0.x 不一定有问题但复现教程场景时跟着原始版本走最稳妥。:: 验证 JDK 版本是否就位 java -version :: License Server 启动后确认端口监听5099 是常见默认端口 netstat -ano | findstr 5099java -version输出里应能看到 17.0.3 字样。License Server 安装完成后把它手动启动一次然后用 netstat 确认 5099 端口处于监听状态。如果端口没有起来先去看 Windows 服务列表里许可相关服务是否处于运行状态以及许可证文件是否已经成功导入。许可服务不要求开机自启但建议设置为手动由部署脚本统一拉起。SQL Server 2019 的安装要注意几点认证模式选混合模式sa 密码提前定好并且记下来这个密码在后续 Database Server 组件配置里会用到排序规则建议选 SQL_Latin1_General_CP1_CI_AS这是 Teamcenter 在英文环境下常用的配置所有库都统一用这个排序规则避免查到一半出现字符串比较错误。安装完成后到 SQL Server 配置管理器里确认 TCP/IP 协议已经启用否则后面 Database Server 组件连接数据库时会报超时。这一步是很多新手容易漏掉的默认情况下 SQL Server 的 TCP/IP 可能是禁用状态只开了命名管道部署脚本连接不上。3. 介质入库解压路径的选择、repotool 日志与活动介质确认3.1 解压路径尽量短为什么是 D:\DeploymentCenter\repository\softwareAWC2406 的安装介质要解压到 Deployment Center 的软件存储库目录下即D:\DeploymentCenter\repository\software。Deployment Center 会扫描这个目录来识别介质。解压后的介质路径要尽量短这个要求不是洁癖而是因为后续生成安装脚本时会把介质路径拼接到各种配置文件和 deploy.bat 参数里。Windows 路径默认 260 字符限制介质目录名太长或者嵌套层级太多脚本跑到一半就可能因为路径超出限制直接中断。# 在 Windows CMD 中执行把介质压缩包解压到软件存储库目录 tar -xf AWC2406_media.zip -C D:\DeploymentCenter\repository\softwareWindows Server 2019 自带 tar 命令可以解压 zip 格式的介质包。-xf表示解压文件-C指定目标目录。解压完成后确认目录结构是D:\DeploymentCenter\repository\software\介质名并且介质名下面直接是安装文件清单不要再套一层同名目录。如果介质是 ISO 格式或分卷压缩包可以先在临时目录解压再把整体内容复制到目标目录效果一样。还要注意介质目录本身的名字不要太长全路径里不要出现空格和中文。Deployment Center 自身安装路径已经是不带空格的短路径介质如果放在D:\Deployment Center\repository\software这种带空格的路径里后续脚本解析时会出现各种奇怪的拼接错误。3.2 添加失败先看 repotool 日志别靠猜介质解压完登录 Deployment Center 后软件存储库里没看到活动介质这种问题很常见。不要急着反复点刷新先去日志目录里找原因。Deployment Center 的介质扫描工具 repotool 会把入库过程的关键信息写到D:\DeploymentCenter\webserver\repotool\logs下这里的日志是排查添加介质失败现场的第一手材料。:: 查看 repotool 日志文件内容 type D:\DeploymentCenter\webserver\repotool\logs\repotool.log :: 只过滤 ERROR 级别的日志行 findstr /i error D:\DeploymentCenter\webserver\repotool\logs\repotool.logtype命令会输出整个日志文件适合日志体积小的时候用。如果日志文件很大用 findstr 过滤 error 关键字更高效。日志里常见两类信息一类是Invalid media或者介质结构无法识别说明解压后的目录层级不对Deployment Center 没有找到它期望的标志性文件另一类是权限相关错误说明当前解压的目录权限没有给到 Deployment Center 的 Web 服务账号。提示介质解压完成后不要立即刷新页面等 30 秒左右再操作。repotool 的目录扫描是按周期触发的不是实时监听。如果日志里找不到任何错误但存储库依然为空可以尝试重启 Deployment Center 的 Web 服务进程再刷新页面。介质扫描服务偶尔会陷入不重新加载目录的僵死状态重启后一般就能恢复正常。3.3 登录 Deployment Center 确认活动介质状态介质入库成功后登录 Deployment Center 的 Web 管理界面在软件存储库页面应该能看到刚添加的介质状态显示为活动。这一步确认很重要介质只有处于活动状态才会出现在后续环境创建的候选列表里。Deployment Center 2406 在一个环境里同时只允许一个活动介质参与构建避免多版本介质互相覆盖。如果环境里同时存在多个介质的旧记录建议把不需要的介质先停用或移除再进行环境创建。这里也需要确认你当前用的登录账号有足够的操作权限。默认的管理账号是 dcadmin如果这个账号密码被改过后面 deploy.bat 传参时也要用对应的新密码否则会认证失败。介质活动状态确认没问题后就可以进入环境创建和组件配置阶段了。4. 环境与组件配置Env_Tc、密码规则与组件顺序的价值4.1 创建环境 Env_Tc环境名决定脚本输出目录登录 Deployment Center 后点击创建环境进入环境后先在概述里修改环境名称教程里的示例叫 Env_Tc。环境名称不是随便起的它会直接影响后续部署脚本的输出路径D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install。如果环境名里带空格或特殊符号生成的脚本目录和 deploy.bat 的路径拼接都会出问题。环境名用途对应脚本目录Env_Tc正式部署环境D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\installEnv_Test测试验证环境D:\DeploymentCenter\repository\deploy_scripts\Env_Test\install环境名建议用字母加下划线的组合例如 Env_Tc、Env_Prod_01。创建完环境后左侧导航会出现环境相关操作入口接下来需要把刚才入库的介质关联到这个环境下。4.2 更新选定的软件与保存环境选项勾什么决定后面出现什么在部署软件页面里可用软件列表会列出当前环境可以关联的介质。选择刚才入库的 AWC2406 介质点击「更新选定的软件」这一步会把介质中的软件包信息同步到当前环境。同步完成后在「已选软件」里确认列出的内容正确再点「转至选项」。选项页面里有一系列部署相关的开关我一般勾选与 AWC 客户端访问相关的常规选项调试类选项保持默认不勾。你在这里勾选的内容会直接影响下一步「组件」页面里列出哪些组件条目。如果后续发现某个组件没有出现在列表里回头检查选项这一步是不是漏勾了相关内容。保存环境选项后回到部署软件页面重新确认一次选中的软件状态确保没有因为选项变更导致软件包被反选。这一阶段所有操作的结果都会被 Deployment Center 记录后续生成安装脚本时会基于这套配置生成部署包所以每一步保存后最好都确认一下页面状态。4.3 组件配置顺序、详细配置入口与密码规则决定成败的三件事组件配置是整条链路里最容易翻车的环节。界面上按顺序列出的组件包括 Active Workspace Client Builder、Active Workspace Gateway、Corporate Server、Database Server、FSC、FSC Group、FSC Keys、Indexer、Indexing Engine、Licensing Server、Microservice Node、Server Manager、Server Manager Cluster Configuration、Teamcenter Web Tier (Java EE)。每个组件名称右侧都有展开查看更详细配置信息的入口里面包括端口号、JVM 参数、依赖的服务地址等。默认值一般够用除非当前端口被占用否则不需要逐个改动。组件之间的依赖关系决定了配置顺序Indexing Engine 依赖 FSC Keys 生成的密钥Server Manager Cluster Configuration 必须等 Server Manager 基础配置完成后再处理Teamcenter Web Tier (Java EE) 放最后因为它依赖 Corporate Server 暴露的服务端口。所以我每次配置都严格按界面顺序从上往下走不跳着配。组件主要职责配置注意点Active Workspace Client Builder生成客户端构建确认版本与介质一致Active Workspace Gateway网关服务主机名不能填错Corporate Server企业级服务端口和依赖地址Database Server数据库连接配置密码禁止特殊符号FSC / FSC Group / FSC Keys文件存储与密钥路径尽量短Indexer / Indexing Engine索引服务依赖 FSC KeysLicensing Server许可服务指向指向已装的 License ServerMicroservice Node微服务节点端口不冲突Server Manager / Cluster服务管理与集群先单机后集群Teamcenter Web Tier (Java EE)Web 层服务最后配置密码规则是这里最需要注意的约束。配置 Database Server 以及 Teamcenter 相关密码时不允许出现特殊符号包括 ! $ % ^ : ; . _ ( ) { } 这二十多个字符。TEMTeamcenter Engineering Manager则允许带特殊符号。# 合规示例TcDb2024xYz字母加数字无特殊符号 # 违规示例TcDb2024包含 符号脚本解析时会被拆成多个参数为什么 Database Server 和 Teamcenter 的密码卡得这么死因为这些密码最终会写进 Deployment Center 自动生成的 XML 配置和 deploy.bat 脚本里。脚本解析时 会被当作参数分隔符 会被当作命令连接符分号和尖括号也有各自的特殊含义一旦密码里出现这些字符生成的脚本执行时就会把密码拆开导致认证失败。与其在脚本里做各种转义不如直接用字母加数字的组合密码省掉一整类问题。TEM 允许特殊符号是因为 TEM 的密码走的是另一条加密链路不经过这个脚本解析器。所以在设计密码时不要把 TC、Database Server 和 TEM 统一用一个模板分开设置并记录在密码管理工具里否则后面排查问题时很难判断是哪个服务的密码出了问题。5. 避坑排查Deployment Center 部署中我踩过的五个典型翻车现场5.1 介质解压了存储库列表还是空白这种现象很常见介质解压到 software 目录repotool 日志里没有 ERROR但刷新存储库列表就是空白。原因大概率是解压出来的目录权限没给足Deployment Center 的 Web 服务账号没有权限读取介质目录。解决方法是给软件存储库目录添加当前部署用户的读取权限或者直接用管理员身份重新解压一次介质让目录继承默认的管理员权限。给完权限后等一轮扫描周期再刷新页面一般就能看到活动介质。5.2 组件状态卡在 90%一直不到 100%我在模拟项目 X 的部署中遇到过一次Indexing Engine 组件状态停在 90%等了十分钟也没变化。检查发现是密码里带了一个 符号Deployment Center 保存配置时没有拒绝但组件依赖处理时解析失败状态机挂起。解决方法是把密码改成字母加数字组合回到部署软件页面重新更新软件再进组件页面逐项保存。不需要删除环境重来改完密码重新走一遍更新流程就能恢复。5.3 deploy.bat 执行时报 dcusername 或 dcpassword 认证失败这个问题通常出现在生成安装脚本后的执行阶段。现象是脚本运行到一半控制台提示认证失败并带着 dcadmin 的用户名。原因是 Deployment Center 的管理员账号密码不是默认值或者创建环境时使用的根本不是 dcadmin。解决方法是先用浏览器登录 Deployment Center 页面确认管理员账号和密码再用正确的参数去跑 deploy.bat。不要试图在 bat 里做双重转义绕过认证那样只会让问题更隐蔽。5.4 Database Server 组件连不上 SQL Server部署脚本执行到数据库初始化步骤时报 SQL 连接超时多半是 SQL Server 的 TCP/IP 协议没有启用。SQL Server 安装后默认可能只开了共享内存和命名管道TCP/IP 处于禁用状态部署脚本通过网络协议连接数据库自然失败。解决方法是到 SQL Server 配置管理器中启用 TCP/IP 协议确认监听端口固定为 1433然后重启 SQL Server 服务。另外检查一下 sa 密码里有没有特殊符号如果带 或分号连接串解析同样会出问题。5.5 安装脚本生成成功但部署包 deploy_XXX.zip 找不到这种现象出现在生成脚本阶段点击生成安装脚本提示成功系统也弹出了部署说明但在 install 目录下没找到对应的 zip 包。原因通常是当前浏览的界面环境不是生成脚本时的那个环境环境名对不上导致部署包生成了不在你预期目录下或者是浏览器弹出了下载窗口压缩包被下载到了用户下载目录。解决方法是仔细看部署说明里提示的路径信息以它为准。如果是浏览器下载行为就把压缩包另存到与 install 目录同级的位置文件名保持 deploy_XXX.zip 不变不要重命名。6. 生成安装脚本与 deploy.bat 执行从组件 100% 到部署完成所有组件状态都变成 100% 后点击转至部署再点击生成安装脚本。脚本生成成功后会提示部署说明里面包含部署包 deploy_XXX.zip 的位置默认在D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install目录下。把这个 zip 包解压到一个路径较短的位置比如D:\Deploy\Env_Tc然后以管理员身份打开 CMD进入解压后的目录执行部署命令。deploy.bat -dcusernamedcadmin -dcpassworddcadmin -softwareLocationD:\DeploymentCenter\repository\software-dcusername和-dcpassword是 Deployment Center 的管理员账号密码要和之前登录 Web 界面用的账号一致。-softwareLocation指向介质解压根目录也就是软件存储库路径告诉部署脚本到哪个位置去读取安装介质内容。执行之前先确认当前目录确实是解压出来的部署包根目录用 dir 命令看一眼再运行。部署过程会持续一段时间结束后可以用服务列表或端口监听来验证关键组件是否起来。:: 验证 AWC 相关服务是否启动 sc query | findstr /i AWC Gateway从那以后我每次生成安装脚本前都会强制走一遍检查流程所有组件状态是否为 100%、Database Server 和 TC 密码是否带禁用符号、主机名是否与 hosts 一致、部署包是否在预期目录。这套检查流程帮我挡掉了好几次半夜部署翻车的风险。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/24 15:32:00 · 阅读 1.2k Teamcenter Deployment Center 部署 AWC2406 全流程指南
简介针对Teamcenter AWC2406部署中的常见问题这份docx笔记整理了从环境准备、依赖服务安装到Deployment Center配置、组件设置及生成部署脚本的完整操作流程适合负责TC实施或维护的工程师按图索骥减少因主机名、网络或组件配置错误导致的中途返工。资源仅1个文件格式为docx共4.67MB内容以分步说明配以路径提示为主重点提醒修改主机名、关闭防火墙与IPv6并完整给出JDK17.0.3、Siemens License Server、SQL Server 2019等前置安装要求随后通过Deployment Center介质添加、环境创建、应用程序与组件逐项配置覆盖Active Workspace Client、Gateway、Corporate Server及Database Server等关键模块同时强调数据库与TC密码禁用特殊符号等易忽略细节。目前已获得312人学习尤其适合首次部署AWC2406、希望系统掌握安装全流程的工程师。借助其中日志排错思路、deploy.bat参数示例与运行命令可快速定位添加介质失败等问题显著提升安装成功率。1. Teamcenter Deployment Center 装 AWC2406先把这条链跑顺再动手AWC2406 的安装难的不是点下一步而是十几个组件之间的依赖关系。手动逐个装 Active Workspace Client、Gateway、Corporate Server、Indexer 这些服务任何一步端口冲突或密码解析出错都要花半天时间排查。用 Teamcenter Deployment Center 2406 可以把「介质入库 → 环境建模 → 组件配置 → 脚本生成 → 一键部署」串成一条可控的链路这也是当前 Teamcenter 环境安装 AWC 的主流方式。这篇文章面向刚接手 Teamcenter 环境、需要在干净服务器上从零部署 AWC2406 的运维和实施工程师按实际操作顺序拆解安装准备、介质入库、组件配置到 deploy.bat 落地的全过程并把我在现场踩过的坑一并写出来。2. 装前准备三件事主机名、网络策略与 JDK/License/数据库顺序2.1 修改主机名与 hosts 映射影响的是许可校验和 URL 生成很多安装教程会用黑色笔记把截图里的主机名盖住提示你改成自己的主机名。这一步看上去无关痛痒实际上它决定了后面 License Server 的许可校验、Active Workspace Gateway 生成的访问 URL、以及部署脚本里所有服务地址的正确性。如果装机时主机名没改到了部署阶段才发现问题改完主机名后 Deploymen Center 生成的脚本里还残留旧主机名只能重新生成环境非常被动。主机名的规范建议用小写字母加数字比如 TcSrv01避免下划线和过长名称。修改完系统主机名后还要在 hosts 文件里补一条主机名到本机回环地址的映射防止许可服务做主机名反查时去请求不存在的 DNS。:: 1) 管理员身份打开记事本编辑 hosts 文件 notepad C:\Windows\System32\drivers\etc\hosts :: 2) 在文件末尾追加一行把主机名解析到本机 127.0.0.1 TcSrv01这里把 127.0.0.1 和主机名之间用 Tab 分隔不要用空格。加这一行的原因是 Teamcenter 的 License Server 在校验许可时会做主机名解析如果 hosts 里没有对应记录服务启动会变慢甚至直接失败。你有内部 DNS 也可以不写但多数实施环境的主机名解析不可控这种本地映射是最稳妥的做法。改完 hosts 之后用hostname命令确认一下当前系统主机名输出结果要和 hosts 里追加的名字一致。如果不一致说明系统主机名还没改成功要重新设置并重启。这一步先做对后面生成安装脚本时 hostname 才会以正确值写入所有配置文件。2.2 关闭防火墙与禁用 IPv6减少网络层变量的干扰Deployment Center 在部署阶段会启动很多服务组件之间的通信端口非常多像 Corporate Server、Microservice Node、Indexing Engine 各自监听不同端口。如果开着 Windows 防火墙每漏一条放行规则部署过程就会在某一步突然失败而且日志不一定直接提示防火墙拦截。所以我一般在内网部署机上先把防火墙全部关闭等整套环境装完、验证通过之后再按实际端口列表把防火墙策略收紧到最小范围。:: 关闭 Windows 防火墙的三个配置文件域、专用、公用 netsh advfirewall set allprofiles state off :: 禁用 IPv6 协议 netsh int ipv6 set state disabled第一条命令把域、专用、公用三种网络配置文件的防火墙统一关闭避免后续服务绑定端口时被拦截。第二条禁用 IPv6 的原因比较玄学在 Windows Server 双栈环境下SQL Server 和 Teamcenter 之间的 TCP 连接有时会解析到 IPv6 地址导致连接超时或报网络不可达而服务本身配置的却是 IPv4 地址。把 IPv6 直接禁掉能让所有连接串老老实实走 IPv4 路径。这个改动重启服务器后完全生效因此建议在安装 JDK 之前就把它设置好。需要留意的是禁用 IPv6 后要确认服务器的物理网卡配置没有强制依赖 IPv6 协议否则重启后可能出现网络异常。对于一台干净的部署机来说这个风险一般是可控的。2.3 JDK 17.0.3、Siemens License Server 与 SQL Server 2019 的安装顺序安装顺序建议是JDK 17.0.3 → Siemens License Server → SQL Server 2019。JDK 必须放在最前面因为 Deployment Center 的 repotool 和后面 Indexing Engine 组件都依赖 Java 运行时JDK 版本不对介质入库时日志会直接报 UnsupportedClassVersionError。JDK 版本尽量用 17.0.3这是 AWC2406 构建基线验证过的版本用更新的 17.0.x 不一定有问题但复现教程场景时跟着原始版本走最稳妥。:: 验证 JDK 版本是否就位 java -version :: License Server 启动后确认端口监听5099 是常见默认端口 netstat -ano | findstr 5099java -version输出里应能看到 17.0.3 字样。License Server 安装完成后把它手动启动一次然后用 netstat 确认 5099 端口处于监听状态。如果端口没有起来先去看 Windows 服务列表里许可相关服务是否处于运行状态以及许可证文件是否已经成功导入。许可服务不要求开机自启但建议设置为手动由部署脚本统一拉起。SQL Server 2019 的安装要注意几点认证模式选混合模式sa 密码提前定好并且记下来这个密码在后续 Database Server 组件配置里会用到排序规则建议选 SQL_Latin1_General_CP1_CI_AS这是 Teamcenter 在英文环境下常用的配置所有库都统一用这个排序规则避免查到一半出现字符串比较错误。安装完成后到 SQL Server 配置管理器里确认 TCP/IP 协议已经启用否则后面 Database Server 组件连接数据库时会报超时。这一步是很多新手容易漏掉的默认情况下 SQL Server 的 TCP/IP 可能是禁用状态只开了命名管道部署脚本连接不上。3. 介质入库解压路径的选择、repotool 日志与活动介质确认3.1 解压路径尽量短为什么是 D:\DeploymentCenter\repository\softwareAWC2406 的安装介质要解压到 Deployment Center 的软件存储库目录下即D:\DeploymentCenter\repository\software。Deployment Center 会扫描这个目录来识别介质。解压后的介质路径要尽量短这个要求不是洁癖而是因为后续生成安装脚本时会把介质路径拼接到各种配置文件和 deploy.bat 参数里。Windows 路径默认 260 字符限制介质目录名太长或者嵌套层级太多脚本跑到一半就可能因为路径超出限制直接中断。# 在 Windows CMD 中执行把介质压缩包解压到软件存储库目录 tar -xf AWC2406_media.zip -C D:\DeploymentCenter\repository\softwareWindows Server 2019 自带 tar 命令可以解压 zip 格式的介质包。-xf表示解压文件-C指定目标目录。解压完成后确认目录结构是D:\DeploymentCenter\repository\software\介质名并且介质名下面直接是安装文件清单不要再套一层同名目录。如果介质是 ISO 格式或分卷压缩包可以先在临时目录解压再把整体内容复制到目标目录效果一样。还要注意介质目录本身的名字不要太长全路径里不要出现空格和中文。Deployment Center 自身安装路径已经是不带空格的短路径介质如果放在D:\Deployment Center\repository\software这种带空格的路径里后续脚本解析时会出现各种奇怪的拼接错误。3.2 添加失败先看 repotool 日志别靠猜介质解压完登录 Deployment Center 后软件存储库里没看到活动介质这种问题很常见。不要急着反复点刷新先去日志目录里找原因。Deployment Center 的介质扫描工具 repotool 会把入库过程的关键信息写到D:\DeploymentCenter\webserver\repotool\logs下这里的日志是排查添加介质失败现场的第一手材料。:: 查看 repotool 日志文件内容 type D:\DeploymentCenter\webserver\repotool\logs\repotool.log :: 只过滤 ERROR 级别的日志行 findstr /i error D:\DeploymentCenter\webserver\repotool\logs\repotool.logtype命令会输出整个日志文件适合日志体积小的时候用。如果日志文件很大用 findstr 过滤 error 关键字更高效。日志里常见两类信息一类是Invalid media或者介质结构无法识别说明解压后的目录层级不对Deployment Center 没有找到它期望的标志性文件另一类是权限相关错误说明当前解压的目录权限没有给到 Deployment Center 的 Web 服务账号。提示介质解压完成后不要立即刷新页面等 30 秒左右再操作。repotool 的目录扫描是按周期触发的不是实时监听。如果日志里找不到任何错误但存储库依然为空可以尝试重启 Deployment Center 的 Web 服务进程再刷新页面。介质扫描服务偶尔会陷入不重新加载目录的僵死状态重启后一般就能恢复正常。3.3 登录 Deployment Center 确认活动介质状态介质入库成功后登录 Deployment Center 的 Web 管理界面在软件存储库页面应该能看到刚添加的介质状态显示为活动。这一步确认很重要介质只有处于活动状态才会出现在后续环境创建的候选列表里。Deployment Center 2406 在一个环境里同时只允许一个活动介质参与构建避免多版本介质互相覆盖。如果环境里同时存在多个介质的旧记录建议把不需要的介质先停用或移除再进行环境创建。这里也需要确认你当前用的登录账号有足够的操作权限。默认的管理账号是 dcadmin如果这个账号密码被改过后面 deploy.bat 传参时也要用对应的新密码否则会认证失败。介质活动状态确认没问题后就可以进入环境创建和组件配置阶段了。4. 环境与组件配置Env_Tc、密码规则与组件顺序的价值4.1 创建环境 Env_Tc环境名决定脚本输出目录登录 Deployment Center 后点击创建环境进入环境后先在概述里修改环境名称教程里的示例叫 Env_Tc。环境名称不是随便起的它会直接影响后续部署脚本的输出路径D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install。如果环境名里带空格或特殊符号生成的脚本目录和 deploy.bat 的路径拼接都会出问题。环境名用途对应脚本目录Env_Tc正式部署环境D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\installEnv_Test测试验证环境D:\DeploymentCenter\repository\deploy_scripts\Env_Test\install环境名建议用字母加下划线的组合例如 Env_Tc、Env_Prod_01。创建完环境后左侧导航会出现环境相关操作入口接下来需要把刚才入库的介质关联到这个环境下。4.2 更新选定的软件与保存环境选项勾什么决定后面出现什么在部署软件页面里可用软件列表会列出当前环境可以关联的介质。选择刚才入库的 AWC2406 介质点击「更新选定的软件」这一步会把介质中的软件包信息同步到当前环境。同步完成后在「已选软件」里确认列出的内容正确再点「转至选项」。选项页面里有一系列部署相关的开关我一般勾选与 AWC 客户端访问相关的常规选项调试类选项保持默认不勾。你在这里勾选的内容会直接影响下一步「组件」页面里列出哪些组件条目。如果后续发现某个组件没有出现在列表里回头检查选项这一步是不是漏勾了相关内容。保存环境选项后回到部署软件页面重新确认一次选中的软件状态确保没有因为选项变更导致软件包被反选。这一阶段所有操作的结果都会被 Deployment Center 记录后续生成安装脚本时会基于这套配置生成部署包所以每一步保存后最好都确认一下页面状态。4.3 组件配置顺序、详细配置入口与密码规则决定成败的三件事组件配置是整条链路里最容易翻车的环节。界面上按顺序列出的组件包括 Active Workspace Client Builder、Active Workspace Gateway、Corporate Server、Database Server、FSC、FSC Group、FSC Keys、Indexer、Indexing Engine、Licensing Server、Microservice Node、Server Manager、Server Manager Cluster Configuration、Teamcenter Web Tier (Java EE)。每个组件名称右侧都有展开查看更详细配置信息的入口里面包括端口号、JVM 参数、依赖的服务地址等。默认值一般够用除非当前端口被占用否则不需要逐个改动。组件之间的依赖关系决定了配置顺序Indexing Engine 依赖 FSC Keys 生成的密钥Server Manager Cluster Configuration 必须等 Server Manager 基础配置完成后再处理Teamcenter Web Tier (Java EE) 放最后因为它依赖 Corporate Server 暴露的服务端口。所以我每次配置都严格按界面顺序从上往下走不跳着配。组件主要职责配置注意点Active Workspace Client Builder生成客户端构建确认版本与介质一致Active Workspace Gateway网关服务主机名不能填错Corporate Server企业级服务端口和依赖地址Database Server数据库连接配置密码禁止特殊符号FSC / FSC Group / FSC Keys文件存储与密钥路径尽量短Indexer / Indexing Engine索引服务依赖 FSC KeysLicensing Server许可服务指向指向已装的 License ServerMicroservice Node微服务节点端口不冲突Server Manager / Cluster服务管理与集群先单机后集群Teamcenter Web Tier (Java EE)Web 层服务最后配置密码规则是这里最需要注意的约束。配置 Database Server 以及 Teamcenter 相关密码时不允许出现特殊符号包括 ! $ % ^ : ; . _ ( ) { } 这二十多个字符。TEMTeamcenter Engineering Manager则允许带特殊符号。# 合规示例TcDb2024xYz字母加数字无特殊符号 # 违规示例TcDb2024包含 符号脚本解析时会被拆成多个参数为什么 Database Server 和 Teamcenter 的密码卡得这么死因为这些密码最终会写进 Deployment Center 自动生成的 XML 配置和 deploy.bat 脚本里。脚本解析时 会被当作参数分隔符 会被当作命令连接符分号和尖括号也有各自的特殊含义一旦密码里出现这些字符生成的脚本执行时就会把密码拆开导致认证失败。与其在脚本里做各种转义不如直接用字母加数字的组合密码省掉一整类问题。TEM 允许特殊符号是因为 TEM 的密码走的是另一条加密链路不经过这个脚本解析器。所以在设计密码时不要把 TC、Database Server 和 TEM 统一用一个模板分开设置并记录在密码管理工具里否则后面排查问题时很难判断是哪个服务的密码出了问题。5. 避坑排查Deployment Center 部署中我踩过的五个典型翻车现场5.1 介质解压了存储库列表还是空白这种现象很常见介质解压到 software 目录repotool 日志里没有 ERROR但刷新存储库列表就是空白。原因大概率是解压出来的目录权限没给足Deployment Center 的 Web 服务账号没有权限读取介质目录。解决方法是给软件存储库目录添加当前部署用户的读取权限或者直接用管理员身份重新解压一次介质让目录继承默认的管理员权限。给完权限后等一轮扫描周期再刷新页面一般就能看到活动介质。5.2 组件状态卡在 90%一直不到 100%我在模拟项目 X 的部署中遇到过一次Indexing Engine 组件状态停在 90%等了十分钟也没变化。检查发现是密码里带了一个 符号Deployment Center 保存配置时没有拒绝但组件依赖处理时解析失败状态机挂起。解决方法是把密码改成字母加数字组合回到部署软件页面重新更新软件再进组件页面逐项保存。不需要删除环境重来改完密码重新走一遍更新流程就能恢复。5.3 deploy.bat 执行时报 dcusername 或 dcpassword 认证失败这个问题通常出现在生成安装脚本后的执行阶段。现象是脚本运行到一半控制台提示认证失败并带着 dcadmin 的用户名。原因是 Deployment Center 的管理员账号密码不是默认值或者创建环境时使用的根本不是 dcadmin。解决方法是先用浏览器登录 Deployment Center 页面确认管理员账号和密码再用正确的参数去跑 deploy.bat。不要试图在 bat 里做双重转义绕过认证那样只会让问题更隐蔽。5.4 Database Server 组件连不上 SQL Server部署脚本执行到数据库初始化步骤时报 SQL 连接超时多半是 SQL Server 的 TCP/IP 协议没有启用。SQL Server 安装后默认可能只开了共享内存和命名管道TCP/IP 处于禁用状态部署脚本通过网络协议连接数据库自然失败。解决方法是到 SQL Server 配置管理器中启用 TCP/IP 协议确认监听端口固定为 1433然后重启 SQL Server 服务。另外检查一下 sa 密码里有没有特殊符号如果带 或分号连接串解析同样会出问题。5.5 安装脚本生成成功但部署包 deploy_XXX.zip 找不到这种现象出现在生成脚本阶段点击生成安装脚本提示成功系统也弹出了部署说明但在 install 目录下没找到对应的 zip 包。原因通常是当前浏览的界面环境不是生成脚本时的那个环境环境名对不上导致部署包生成了不在你预期目录下或者是浏览器弹出了下载窗口压缩包被下载到了用户下载目录。解决方法是仔细看部署说明里提示的路径信息以它为准。如果是浏览器下载行为就把压缩包另存到与 install 目录同级的位置文件名保持 deploy_XXX.zip 不变不要重命名。6. 生成安装脚本与 deploy.bat 执行从组件 100% 到部署完成所有组件状态都变成 100% 后点击转至部署再点击生成安装脚本。脚本生成成功后会提示部署说明里面包含部署包 deploy_XXX.zip 的位置默认在D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install目录下。把这个 zip 包解压到一个路径较短的位置比如D:\Deploy\Env_Tc然后以管理员身份打开 CMD进入解压后的目录执行部署命令。deploy.bat -dcusernamedcadmin -dcpassworddcadmin -softwareLocationD:\DeploymentCenter\repository\software-dcusername和-dcpassword是 Deployment Center 的管理员账号密码要和之前登录 Web 界面用的账号一致。-softwareLocation指向介质解压根目录也就是软件存储库路径告诉部署脚本到哪个位置去读取安装介质内容。执行之前先确认当前目录确实是解压出来的部署包根目录用 dir 命令看一眼再运行。部署过程会持续一段时间结束后可以用服务列表或端口监听来验证关键组件是否起来。:: 验证 AWC 相关服务是否启动 sc query | findstr /i AWC Gateway从那以后我每次生成安装脚本前都会强制走一遍检查流程所有组件状态是否为 100%、Database Server 和 TC 密码是否带禁用符号、主机名是否与 hosts 一致、部署包是否在预期目录。这套检查流程帮我挡掉了好几次半夜部署翻车的风险。希望帮到你。本文还有配套的精品资源点击获取