简介：围绕Teamcenter AWC2406的安装实践，整理了一份基于Deployment Center部署的完整操作笔记，主要面向实施工程师与系统管理员，帮助规避安装过程中常见的环境冲突与配置盲点。资源为单个docx文档，压缩包大小4.67MB，内容按安装流程分步展开：从修改主机名、关闭防火墙与IPv6，到安装JDK17.0.3、Siemens License Server和SQL Server 2019，再到通过Deployment Center添加介质、创建环境与组件配置，最后生成部署脚本并执行deploy.bat。文档还特别提示了Database Server与TC密码不允许包含特殊符号、TEM支持特殊符号等易错细节，并给出介质添加失败时的日志排查路径，具备较强的实操参考价值。已有312人学习，适合需要按步骤完成AWC2406环境搭建或进行同类Teamcenter部署的读者对照使用。

1. 用 Deployment Center 装 AWC2406：从介质入库到部署脚本落地的全景图

用 Deployment Center 安装 AWC2406，很多人第一次上手都会卡在同一个地方：明明介质放进存储库了，环境也建了，最后跑 deploy.bat 却一路报错，对着日志干瞪眼。这篇笔记把整套流程拆成可复现的步骤，从改主机名、关防火墙、禁 IPv6，到 JDK 17.0.3、License Server 4、SQL Server 2019 三个基础组件，再到介质入库、组件配置和脚本生成，最后落到部署命令和验证方法。适合刚接手 Teamcenter 环境搭建的运维和实施工程师，也适合被现场各种奇怪报错折腾过的熟手对照排查。本文只讲安装参考，更细节的内容请以官方文档为准。

2. 环境准备的四件事：主机名、防火墙、IPv6 与 JDK/License/数据库

AWC2406 这套东西对环境的敏感程度超出多数人的预期。很多部署失败并不是配置步骤错了，而是环境里某个基础项没对齐。下面这几件事，按先后顺序做，别跳。

2.1 hosts 与主机名：先改掉再动别的

安装文档里主机名被黑色笔记覆盖了，改成自己的即可。这里的核心逻辑是：Deployment Center 在生成部署脚本时，会把当前主机名写进各组件的配置文件中，后续服务间通信全靠这个名称去找机器。如果机器名和 hosts 里的解析对不上，装完的服务会互相找不到对方。

先确认当前主机名，再编辑 hosts 文件：

# 查看当前主机名 hostname # 查看本机 IP（找 IPv4 地址那段） ipconfig /all # 以管理员身份打开记事本，编辑 hosts 文件 notepad C:\Windows\System32\drivers\etc\hosts

在 hosts 文件末尾追加一行，格式是“IP 主机名”，例如：

192.168.1.100 tc-server

追加完保存，然后在 CMD 里执行ping tc-server，能解析到本机 IP 就说明生效了。

这里要注意三点：主机名里不要带下划线、空格和特殊字符，Deployment Center 生成的脚本里主机名是直接拼进路径和连接字符串的，带下划线会出现玄学问题；hosts 里不要出现两个不同 IP 指向同一主机名；如果这台机器后续会加入域，提前确认主机名和域账号的对应关系，装完再改主机名属于给自己挖坑。

2.2 关防火墙、禁 IPv6：网络层面的两个开关

SQL Server 2019、License Server、TC 服务之间走的是主机名解析和动态端口，防火墙策略没有放行会直接超时。IPv6 的问题更隐蔽：主机名优先解析到 IPv6 地址，而服务监听的是 IPv4，结果就是连接被拒或反复超时。在隔离的内网实施环境里，常规做法是先把防火墙和 IPv6 都关掉，等部署验证通过后再按安全要求补白名单。

# 关闭防火墙（域/专用/公用三档一起关，仅限内网实施环境） Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False # 禁用 IPv6：DisabledComponents 设为 0xFF 表示全接口禁用 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name "DisabledComponents" -Value 0xFF # 改完注册表需要重启系统才生效

其中DisabledComponents的0xFF是禁用所有 IPv6 接口的常规取值，重启后可以在 CMD 里执行ipconfig查看，IPv6 地址不再出现就是成功了。注意，公网或生产环境不要关防火墙，这里只针对隔离的实施环境。如果现场不允许关防火墙，至少放行 SQL Server 的 1433 端口、License Server 的监听端口以及 TC 服务之间的动态端口范围，否则后面组件状态会一直卡着不动。

2.3 JDK 17.0.3、License Server 与 SQL Server 2019：版本别乱动

这三个基础组件是后面一切的前提。JDK 版本必须对齐 JDK 17.0.3，不要随手升级小版本，AWC2406 对 JDK 版本有具体校验，版本不对时组件配置阶段会直接报错。License Server 4 负责 TC 的授权服务，服务必须处于启动状态，端口不能被占用。SQL Server 2019 承担数据库角色，建议在安装时选择混合认证模式，因为 Deployment Center 后续建环境要用 SQL 账号去连库。

JDK 配置的常见做法是设置 JAVA_HOME，并把%JAVA_HOME%\bin追加到 Path：

# 命令行设置 JAVA_HOME（setx 只对之后新开的窗口生效） setx JAVA_HOME "D:\JDK17.0.3" # Path 建议到系统属性 -> 环境变量里手动追加 %JAVA_HOME%\bin # 新开一个 CMD 验证版本，必须是 17.0.3 java -version

不推荐用setx PATH的方式改 Path，setx 会把变量值整体覆盖，存在截断风险。SQL Server 2019 安装时记住实例名、端口和排序规则，Deployment Center 组件配置页里要填的就是这些信息。License Server 装完先确认服务是“正在运行”，点击服务管理器里能看到对应服务状态。三件套全部就绪后，再进入介质入库环节。

3. 介质入库：解压路径、活动介质与 repotool 日志排查

介质入库是 Deployment Center 安装流程里第一个真正会卡人的环节。这一步做不好，后面的环境创建、组件配置全都没法进行。

3.1 解压介质：路径尽量短是硬要求

安装介质需要解压后放到D:\DeploymentCenter\repository\software目录下，路径要尽量短。这背后的原因是：Deployment Center 在解析介质、读取产品定义文件时，会把完整路径拼进内部命令，Windows 对路径长度有限制，路径过长时介质扫描会失败，甚至介质文件拷贝到存储库时会中途断掉。

我一般会把介质解压成类似D:\DeploymentCenter\repository\software\AWC2406这样一层结构，不要让介质目录嵌套太深。比如某个介质解压出来是D:\DeploymentCenter\repository\software\AW2406\product\disk1是正常的，但如果变成D:\DeploymentCenter\repository\software\install\packages\AWC2406\2024\disk1就太深了，建议重新整理。

另外一个容易被忽略的点是路径里的字符。介质目录和上级目录都不要出现中文、空格和&这类特殊符号，Deployment Center 内部脚本对路径的解析比较原始，空格会直接导致介质识别失败。解压时右键选择“解压到当前文件夹”，保持目录结构完整，不要只拷贝部分文件。

3.2 登录 Deployment Center 添加介质：失败先看 repotool 日志

介质放进 software 目录后，打开浏览器登录 Deployment Center，进入“软件存储库”，正常情况下能看到刚放入的介质显示为活动状态。这一步的原理是 Deployment Center 会周期性扫描仓库目录，把识别到的产品定义读入存储库列表，所以介质结构不完整或路径异常时，列表里就是空的。

如果添加失败，不要反复试，去D:\DeploymentCenter\webserver\repotool\logs目录下看日志。日志文件里记录了扫描介质的详细过程，包括读取了哪个目录、为什么判定介质无效。常见原因有三个：介质目录访问权限不足、解压过程中文件缺失、路径过长。

# 切换到 repotool 日志目录 cd /d D:\DeploymentCenter\webserver\repotool\logs # 查看最近的日志文件（按修改时间排序） dir /o-d

日志里如果出现“access denied”或“permission denied”字样，是权限问题，确认当前账号对D:\DeploymentCenter\repository\software有完全控制权。如果出现“invalid product definition”或“file not found”，说明解压不完整或介质目录结构被改过，回到 3.1 重新解压。如果日志里提示路径过长，把介质挪到更短路径后再扫描一次。

注意：介质添加成功后，存储库里显示的是“活动介质”。如果状态不是活动，而是“无效”或“错误”，说明介质本身有问题，不要继续往下走。

4. 环境与组件配置：软件更新、十六个组件和密码符号限制

环境配置是 Deployment Center 安装流程的核心环节，耗时长，也是报错集中区。整个流程可以拆成环境创建、软件更新、选项保存、应用程序配置、组件配置五个步骤，顺序不要打乱。

4.1 创建环境并改名：Env_Tc 从哪改

登录 Deployment Center 后，先创建一个新环境，然后进入环境的“概述”页面，把名称改成类似Env_Tc这样的自定义名字。环境名会直接出现在后续生成的部署包文件名里，比如deploy_Env_Tc.zip，取一个好认的名字方便后期分辨多个部署环境。

环境创建完成后，左侧导航会切换到这个环境的工作区。改名这一步很多人会跳过，但默认环境名在生产环境里有多个部署包时完全分不清，建议第一时间改掉。改完保存，环境名在后续所有步骤里都会用上。

4.2 软件更新与环境选项：先刷新再勾选

回到“部署软件”页面，这一步的作用是把存储库里的介质关联到当前环境。先在“可用软件”里找到对应介质并勾选，点击“更新选定的软件”，Deployment Center 会把介质关联到当前环境并同步产品信息。更新完成后，确认“已选软件”列表里有正确内容，再点击“转至选项”。

# 这一步没有命令行操作，但注意观察界面上的状态变化 # 更新完成后，已选软件列表必须出现介质名称

如果“已选软件”是空的，说明介质没有正确关联，返回存储库确认介质状态，不要强行走下去。进入“选项”页后，勾选需要的安装选项，然后保存环境选项。有些选项之间是联动关系，勾选主选项后，子选项会自动带出。保存环境选项时如果报错，优先检查是不是密码字段里带了特殊符号，这条见 4.4。

4.3 应用程序与组件清单：十六个组件按顺序过

在“应用程序”里可以添加可用的应用程序，选中后点击“更新选定的应用程序”，再点击“转至组件”。组件配置是整个流程里最耗时的部分，需要按顺序逐个配置各组件的详细信息。点组件行后面的详情图标，能看到更详细的配置项，包括主机名、端口、服务账号、数据库连接信息等。

AWC2406 的组件清单一共十六个，按界面里的顺序逐个过：

每个组件配置完成后，界面上的状态值会更新。组件配置页里填的主机名一定要和 2.1 里 hosts 配置的一致，填 IP 或填别名都可能造成安装后的服务间通信异常。

4.4 密码里的特殊符号黑名单：连 . 和 _ 都不行

这是整套安装流程里最容易翻车的地方。Deployment Center 中配置 Database Server 以及 TC 的密码时，不允许出现! @ $ % = & ' " ^ : ; . _ < > ( ) { }这些特殊符号。注意，这个黑名单里包括_和.，这两个符号在大多数系统里被认为是安全字符，但在这里明确不行。

# 密码示例（合法）： # TcAdmin2024 # 密码示例（不合法，会报错）： # Tc_Admin_2024 # Tc.Admin@2024

这条限制的坑在于：你在环境选项或组件配置页面输入含特殊符号的密码，界面上可能不会立刻报错，而是在保存环境选项时给一个模糊的错误提示，或者到组件配置阶段 Database Server 连接失败。现场排查时容易绕到数据库服务本身的问题上，实际就是密码格式不合法。

TEM 是个例外，它允许带特殊符号。所以不要用同一套密码逻辑去套所有组件，Database Server 和 TC 的密码用纯字母数字组合最稳妥，TEM 的密码可以单独设计。

4.5 组件状态到 100%：生成脚本前最后一道检查

所有组件配置完成后，逐个确认状态值都变成 100%。这一步不能急，任何一个组件不是 100%，点击“转至部署”生成的脚本都有可能缺内容，装到一半报错再回来看就晚了。

确认全部 100% 后点击“转至部署”，再点击“生成安装脚本”。生成成功后系统会提示部署说明，里面有部署包的存放位置和解压路径。部署包一般位于D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install目录下，文件名类似deploy_XXX.zip，其中 XXX 对应环境名。

5. 踩坑排查：介质失败、空列表与 deploy.bat 报错的四个现场

下面四类问题是我在部署现场和虚拟机上反复踩过的，按“现象 → 原因 → 解决”的结构整理，遇到类似报错可以直接对照。

5.1 介质添加失败，存储库看不到活动介质

现象：介质文件已经复制到D:\DeploymentCenter\repository\software目录，登录 Deployment Center 后在软件存储库中看不到任何活动介质，刷新也没有反应。

原因：介质所在目录权限不足，或者解压过程中文件缺失；另一个高频原因是路径过长，导致扫描进程读取介质定义文件时中断。

解决：先看D:\DeploymentCenter\webserver\repotool\logs下的日志。权限问题就给当前账号授予 repository 目录的完全控制权；路径问题就把介质挪到更短的路径下重新扫描。

5.2 已选软件为空，无法进入选项页

现象：在“部署软件”页面勾选介质后点击“更新选定的软件”，回到页面一看“已选软件”列表还是空的，“转至选项”按钮无法点击。

原因：介质没有正确关联到当前环境。常见是介质入库时未被识别为可部署软件，或者介质的版本与 Deployment Center 2406 不匹配。

解决：回到软件存储库确认介质状态是“活动”；把介质解压到短路径后重新执行更新操作。如果介质文件本身来自非官方渠道，先检查解压后的结构里是否存在产品定义文件，缺失的话需要重新获取完整介质。

5.3 密码含 . 或 _ 导致环境选项保存报错

现象：环境选项填写阶段，密码字段里用了类似Tc_Admin_2024的写法，点击保存环境选项时报错，提示信息比较笼统，不指向具体字段。

原因：Database Server 和 TC 的密码不允许特殊符号，黑名单里包含_和.，这两个字符在多数系统里合法，容易忽视。

解决：把密码改为纯字母数字组合，比如TcAdmin2024，重新保存。TEM 的密码允许特殊符号，不要被这条限制影响到 TEM 环境配置。

5.4 deploy.bat 报错找不到软件位置

现象：解压部署包后，以管理员身份运行 CMD 执行deploy.bat -dcusername=dcadmin -dcpassword=dcadmin -softwareLocation=D:\DeploymentCenter\repository\software，提示找不到软件源或某个介质不存在。

原因：-softwareLocation参数指向了具体介质子目录，而不是介质仓库根目录。脚本要求这个路径下直接是各个介质文件夹，如果填成D:\DeploymentCenter\repository\software\AWC2406，脚本会往下找，找不到正确介质。

解决：确认-softwareLocation参数值为D:\DeploymentCenter\repository\software，同时检查盘符、目录名是否完全一致，注意路径里不要有结尾反斜杠。

6. 部署执行与验证：deploy.bat 参数和一条确认链路

部署包生成成功后，在D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install目录下找到deploy_XXX.zip，解压到某个位置。以管理员身份运行 CMD，进入解压后的目录，执行部署命令。

# 进入解压后的部署包目录 cd /d D:\DeploymentCenter\deploy_scripts\Env_Tc\install # 执行部署脚本（账号密码为 Deployment Center 的登录账号） deploy.bat -dcusername=dcadmin -dcpassword=dcadmin -softwareLocation=D:\DeploymentCenter\repository\software

参数说明：-dcusername和-dcpassword是 Deployment Center 的登录账号，不是 Windows 账号；-softwareLocation是介质所在仓库根目录，必须指向D:\DeploymentCenter\repository\software这一层，不要指到具体子目录。

部署过程会在 CMD 窗口里输出进度，长时间没有输出不代表卡死，去看部署包解压目录下的日志文件确认当前步骤。部署完成后，按部署说明里记录的访问地址打开 AWC 登录页，能看到登录界面就算基本通了。从那以后我每次在组件页点“转至部署”前，都会强制过一遍所有组件的状态值，确认全部 100% 才生成脚本，这个习惯帮我省掉了好几次半夜回滚。希望帮到你。

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