简介：针对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 5099

java -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\software

AWC2406 的安装介质要解压到 Deployment Center 的软件存储库目录下，即D:\DeploymentCenter\repository\software。Deployment Center 会扫描这个目录来识别介质。解压后的介质路径要尽量短，这个要求不是洁癖，而是因为后续生成安装脚本时，会把介质路径拼接到各种配置文件和 deploy.bat 参数里。Windows 路径默认 260 字符限制，介质目录名太长或者嵌套层级太多，脚本跑到一半就可能因为路径超出限制直接中断。

# 在 Windows CMD 中执行，把介质压缩包解压到软件存储库目录 tar -xf AWC2406_media.zip -C D:\DeploymentCenter\repository\software

Windows 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.log

type命令会输出整个日志文件，适合日志体积小的时候用。如果日志文件很大，用 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、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 暴露的服务端口。所以我每次配置都严格按界面顺序从上往下走，不跳着配。

密码规则是这里最需要注意的约束。配置 Database Server 以及 Teamcenter 相关密码时，不允许出现特殊符号，包括 ! @ $ % = & ' " ^ : ; . _ < > ( ) { } 这二十多个字符。TEM（Teamcenter Engineering Manager）则允许带特殊符号。

# 合规示例：TcDb2024xYz，字母加数字，无特殊符号 # 违规示例：Tc@Db2024，包含 @ 符号，脚本解析时会被拆成多个参数

为什么 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 -dcusername=dcadmin -dcpassword=dcadmin -softwareLocation=D:\DeploymentCenter\repository\software

-dcusername和-dcpassword是 Deployment Center 的管理员账号密码，要和之前登录 Web 界面用的账号一致。-softwareLocation指向介质解压根目录，也就是软件存储库路径，告诉部署脚本到哪个位置去读取安装介质内容。执行之前先确认当前目录确实是解压出来的部署包根目录，用 dir 命令看一眼再运行。

部署过程会持续一段时间，结束后可以用服务列表或端口监听来验证关键组件是否起来。

:: 验证 AWC 相关服务是否启动 sc query | findstr /i "AWC Gateway"

从那以后，我每次生成安装脚本前都会强制走一遍检查流程：所有组件状态是否为 100%、Database Server 和 TC 密码是否带禁用符号、主机名是否与 hosts 一致、部署包是否在预期目录。这套检查流程帮我挡掉了好几次半夜部署翻车的风险。希望帮到你。

本文还有配套的精品资源，点击获取