AWC2406部署实战：Deployment Center配置与验证

简介：面向 Teamcenter 实施与运维人员的 AWC2406 部署参考文档，聚焦通过 Deployment Center 完成 Active Workspace Client 2406 安装配置的全过程，适合具备中间件与数据库基础、希望梳理标准化部署流程的读者。压缩包内含 1 个 docx 文件，大小约 4.67MB，便于集中查阅、团队传阅与实施现场对照。内容覆盖环境预检、JDK 与许可服务、SQL Server、安装介质入库、环境与应用程序配置、组件参数设置及部署脚本生成等环节，并附主机名与网络设置、防火墙及 IPv6 处理、存储库路径简短、日志目录定位、环境命名、密码规则差异等细节，对配置顺序、关键参数与校验条件作出说明，可帮助读者建立从准备到部署验证的整体思路。已有 312 人学习，可作为实施前预研、过程对照、问题定位与安装异常排查的辅助材料，也适合不同经验层次的实施人员按需查阅。

1. 装 AWC2406 之前：主机名、防火墙和 IPv6 先定下来

用 Teamcenter Deployment Center 部署 AWC2406，真正让人返工的不是点错哪个按钮，而是机器本身没准备好。我见过一台测试机，主机名还是装系统时随机生成的那串字母，hosts 没动过，防火墙开着，IPv6 也开着，介质入库那一步就卡住了，日志里全是指向另一个地址的解析记录。这套环境在研发部门很常见，Teamcenter 加 Active Workspace 一整套组件几十个，装一次大半天，装坏一次回滚更久。这篇记录面向第一次上手 AWC2406 的开发者，也面向想把安装步骤固化成清单的老手，从改主机名一路写到deploy.bat跑完怎么验证。材料里标黑的位置是主机名，照着换成自己的机器名即可，其余参数照抄。

2. 依赖装什么版本：JDK 17.0.3、License Server 4 与 SQL Server 2019

AWC2406 这套东西对依赖版本是挑剔的，JDK 不是随便找个 8 或 11 就顶上，SQL Server 也不是装完默认配置就能用。这一章把三个前置件的版本、安装路径和关键参数定死，后面 Deployment Center 才不会在配置阶段给你摆脸色。

2.1 JDK 17.0.3 的安装路径与环境变量

JDK 版本必须是 17.0.3，这是这套介质配套的运行时基线，装 17 的其他小版本或者 21 都可能在某些组件启动时报类版本不匹配。安装路径我一般固定成C:\Java\jdk-17.0.3，中间不留空格、不留中文、不带括号——后面部署脚本会把这个路径写进组件启动参数，路径里一旦有空格，某些老组件拼命令行时就会断掉。

安装完别急着点下一步，先把系统级环境变量写好。用管理员权限开 PowerShell：

# 以管理员身份运行，写入系统级 JAVA_HOME [Environment]::SetEnvironmentVariable("JAVA_HOME", "C:\Java\jdk-17.0.3", "Machine") # 取当前系统 Path，追加 bin 目录后写回，注意不要覆盖原有内容 $oldPath = [Environment]::GetEnvironmentVariable("Path", "Machine") [Environment]::SetEnvironmentVariable("Path", "$oldPath;C:\Java\jdk-17.0.3\bin", "Machine")

第一行的Machine表示写到系统变量而不是当前用户变量，服务账户启动的进程才能读到；第二段先取再拼，直接SetEnvironmentVariable硬写一个 Path 会把系统原有的路径全冲掉，这是很多人机器上其他工具突然找不到的原因。写完之后必须新开一个终端验证，旧窗口里的环境变量是缓存值：

java -version

输出里出现java version "17.0.3"才算过。如果机器上还留着旧版本 JDK，where java会列出多条路径，按 PATH 里的先后顺序取第一条，所以追加时注意别把新路径塞到旧路径后面。

2.2 Siemens License Server 4 的许可服务落地

许可服务要装在应用服务器之前，组件配置阶段 Licensing Server 那一项会去找它，服务没起来那一步就红。安装时端口保持默认，我一般用 28000 这一段，装完把许可文件放到固定目录，比如D:\License\，文件名别带空格和中文。

服务注册用自带的 lmtools 界面最稳，也可以在命令行里起：

:: 以管理员身份运行，注册并启动许可服务 lmgrd.exe -c D:\License\license.dat -l D:\License\lmgrd.log

-c指定许可文件，-l指定日志，日志一定要开，许可检不出来的时候这是唯一的黑匣子。用服务方式常驻时，登录账户给本地系统账户，给普通域账户的话重启后服务起不来是常见现象。验证许可是否真的在发：

lmutil lmstat -c 28000@tc2406app -a

-c后面是端口@主机名，主机名必须和你在 hosts 里写的那条完全一致，写成 IP 也行，但两边不能一半 IP 一半主机名，否则许可检出会时好时坏。输出里能看到 feature 列表和到期时间就算通了。

2.3 SQL Server 2019 的排序规则与实例参数

数据库这一层有三个参数必须在建库之前定死，装完再改代价很大。第一是排序规则，选SQL_Latin1_General_CP1_CI_AS，这是这套组件默认预期的排序规则，用 Windows 默认安装很容易落到别的规则上，后面 Database Server 组件配置时会直接拒绝继续。第二是身份验证模式，必须选混合模式并设 sa 密码。第三是 TCP/IP 协议要启用，端口保持 1433。

装完用 SSMS 连上去核对两条：

-- 核对排序规则与身份验证模式 SELECT SERVERPROPERTY('Collation') AS collation_name, SERVERPROPERTY('IsIntegratedSecurityOnly') AS windows_auth_only;

collation_name要等于你选的那条，windows_auth_only返回 0 表示混合模式已开。返回 1 说明只开了 Windows 认证，要去实例属性里改成混合模式并重启 SQL 服务。接着确认监听：

-- 确认实例真的在监听 TCP，而不是只有共享内存 EXEC xp_readerrorlog 0, 1, N'Server is listening on';

有Server is listening on [ 'any' <ipv4> 1433]这一行才算通。这里提前交代一句密码：sa 的密码以及后面 Deployment Center 里 Database Server 的密码，都不能带! @ $ % = & ' " ^ : ; . _ < > ( ) { }这些字符，统一用大小写字母加数字的组合，长度够就行。这条限制踩过的人最多，后面第 5 章还会展开。

3. Deployment Center 2406 落地：介质入库与存储库路径规划

Deployment Center 本身是个 Web 应用，装完之后所有操作都在浏览器里点。它的安装路径和软件存储库路径要一次规划好，中途改路径等于把已经入库的介质全部作废重来。

3.1 安装路径与软件存储库的目录约定

安装路径我固定成D:\DeploymentCenter，不装 C 盘，也不装带空格的Program Files。软件存储库就是它下面的repository\software，这个目录是后面所有介质的家：

# 建存储库目录，顺便确认磁盘剩余空间够放介质 New-Item -ItemType Directory -Force -Path D:\DeploymentCenter\repository\software | Out-Null Get-PSDrive D | Select-Object Used, Free

介质解压后的层级要尽量浅。Deployment Center 在扫描存储库时会递归找描述文件，层级一深，加上解压出来的名字本来就长，很容易顶到 Windows 的路径长度限制，表现就是介质一直停在处理中或者压根不出现。我的习惯是解压到software\awc2406这一层，下面直接就是cdrom、setup这类目录，不要再套一层版本号再套一层日期。

还有一条容易被忽略的：存储库目录的 NTFS 权限要给出 Deployment Center 的服务账户读写权限，只给读的话入库能过，后面生成部署脚本写文件时会失败。

3.2 介质解压、入库与日志定位

解压用 7-Zip 命令行，-o后面跟目标目录，注意-o和路径之间没有空格：

# 解压 AWC2406 介质到短路径，-y 覆盖已有文件 & "C:\Program Files\7-Zip\7z.exe" x "E:\media\AWC2406.zip" ` -o"D:\DeploymentCenter\repository\software\awc2406" -y

解压完用浏览器登录 Deployment Center，默认管理员是dcadmin，进去在软件存储库页面能看到活动的介质。等一两分钟刷新一次，状态从处理中转为活动才算入库成功。

入库失败不用猜，日志就在D:\DeploymentCenter\webserver\repotool\logs下面，盯着实时刷：

# 追踪最新的入库日志，入库卡住时开着这个窗口 Get-Content D:\DeploymentCenter\webserver\repotool\logs\*.log -Tail 100 -Wait

常见报错无非三类：找不到描述文件（解压层级错了或者解压不完整）、路径过长（换更短的目录重来）、权限不足（服务账户没有写权限）。日志里通常会把出问题的绝对路径打出来，照着那个路径去核对，比反复重装快得多。

4. 环境与组件配置：从 Env_Tc 到状态 100%

介质入库只是把料备齐，真正决定装出来能不能用的，是环境、应用程序、组件这三层配置的顺序和参数。这一章按界面上的实际点击顺序走一遍，每一步都说明白了再点下一屏。

4.1 创建环境与选定软件、选项

在 Deployment Center 里新建一个环境，名字起短一点，我用Env_Tc。这个名字会变成部署脚本的目录名，太长会在生成deploy_XXX.zip时出问题。建完进入环境，在概述里可以改环境名称，改完记得保存。

接着回到部署软件页，在可用软件里勾选刚入库的那份 AWC2406 介质，点「更新选定的软件」，确认已选软件列表里显示的是正确版本，再点「转至选项」。选项页是一堆勾选框，按现场实际需求勾，勾完保存环境选项。

这一步的取舍点是：选项一旦保存，后面生成脚本时会写进配置，改选项等于重新生成一遍脚本再重跑部署，时间成本不低。所以选项页不要一路默认下一步，尤其是跟语言、部署模式、是否包含示例数据相关的几条，先和用这套环境的人对齐再勾。

4.2 应用程序与组件顺序配置

进到应用程序页，把可用的应用程序加进来，点「更新选定的应用程序」，再点「转至组件」。组件页是一长串条目，必须按顺序配，前面的没配完，后面的某些字段会是灰的。完整的清单是这样：

每一项右侧都有展开按钮，点开能看到更细的字段，别嫌烦，主机名、端口、目录这三类字段错一个，部署完就是起不来。主机名统一写 hosts 里那条，不要这里写短名那里写全名。

密码是这一步的高危区。Deployment Center 里配 Database Server 的密码和 TC 的密码时，不允许出现特殊符号，! @ $ % = & ' " ^ : ; . _ < > ( ) { }全都不行，逗号句号这类标点也别用，纯字母数字最保险。TEM 那边允许带特殊符号，但两套密码规则不一致的时候，人很容易记混，我的做法是整套环境统一用同一套无特殊符号的强密码，省得后面排查登录问题时先怀疑自己。

4.3 生成安装脚本与部署包位置

所有组件配完，每一行的状态都走到 100% 之后，点「转至部署」，再点「生成安装脚本」。生成成功会给出部署说明，脚本包落在：

D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install\deploy_XXX.zip

把这个 zip 拷到一个独立目录解压，别在原地解压——原地解压出来的文件和 Deployment Center 自己的目录混在一起，出问题不好清。解压完以管理员身份开 CMD，进到解压路径执行：

:: 以管理员身份运行，参数按现场实际替换 deploy.bat -dcusername=dcadmin -dcpassword=dcadmin ^ -softwareLocation=D:\DeploymentCenter\repository\software

三个参数的含义：-dcusername和-dcpassword是 Deployment Center 的登录账号，脚本要用它回连服务端拉配置；-softwareLocation必须和存储库路径一字不差，写成反斜杠结尾、少一级目录、或者写成映射盘符，都会让脚本找不到介质。命令行里的^是换行续行符，实际执行时写成一行也行。

脚本跑起来之后不要关窗口，它会把每个组件的安装过程打到控制台，同时写日志。这个过程二三十分钟起步，中途看着不动也别急着 Ctrl+C，很多组件是在等数据库建表。真卡死了先看日志最后几十行，再决定要不要重跑。

5. 常见问题排查：介质入库、密码字符和脚本执行的五个坑

装这套环境，报错信息往往只有一句「失败」，具体原因得自己去挖。下面五条是我自己踩过的，按现象、原因、解决三段写，对照着看能省不少时间。

5.1 介质入库阶段的两个坑

现象一：介质一直显示处理中，刷新多少次都不变成活动状态，日志里也没有明显报错。

原因：解压层级太深，扫描时路径撞上了长度限制，工具读不到底层的描述文件，于是既不算成功也不报错。另一个可能是 zip 解压时中断过，文件不完整但目录结构看起来是好的。

解决：把D:\DeploymentCenter\repository\software下的东西清空，重新解压到software\awc2406这种两层结构，解压完对比一下原始 zip 里的文件数量。改完再等两分钟刷新。如果还是不行，把 repotool 日志整个拷出来搜error，里面会打出扫描到的绝对路径，一看就知道深浅。

现象二：入库成功，但生成部署脚本时报找不到介质。

原因：入库时用的是 A 路径，-softwareLocation传的是 B 路径，或者中途把存储库目录挪过位置。Deployment Center 记的是入库那一刻的绝对路径。

解决：确认环境里配置的软件位置和脚本参数完全一致，路径统一用D:\DeploymentCenter\repository\software，不要在两者之间加\结尾，也不要写成网络路径。

5.2 环境配置阶段的两个坑

现象三：Database Server 那一项填完密码，点下一步就报校验不通过，密码明明是对的。

原因：密码里带了@、!或.这类字符。Deployment Center 对 Database Server 和 TC 的密码有明确限制，特殊符号会直接在配置阶段被拦；更麻烦的是有的组件在配置阶段能过，部署到一半连数据库时才失败，表现成服务起不来。

解决：全部改成字母加数字的组合，长度 12 位以上。改完不是只改这一处，凡是引用同一套密码的组件都要跟着改，包括后面服务启动账户的密码。这也是我建议整套环境统一密码规则的原因，改一处漏一处，排查时会怀疑到数据库本身。

现象四：组件配置时主机名能填进去，部署完各组件互相连不上，日志里全是解析失败。

原因：主机名和 IP 的对应关系没写进 hosts，或者机器上 IPv6 还开着，解析时优先拿到了 IPv6 地址，而组件之间只按 IPv4 通信。防火墙也常被忽略，测试机上图省事没关，端口就是不通。

解决：先把 hosts 补上，主机名和 IP 一一对应，改完刷新 DNS 缓存；再把网卡上的 IPv6 关掉；防火墙在安装期间直接关闭，装完再按端口白名单开。

# 追加 hosts 记录，IP 和主机名换成自己的 Add-Content -Path "$env:SystemRoot\System32\drivers\etc\hosts" ` -Value "`n192.168.10.21 tc2406app" -Encoding ASCII # 关闭所有网卡上的 IPv6 绑定，改完重启系统生效 Get-NetAdapterBinding -ComponentID ms_tcpip6 | Disable-NetAdapterBinding # 安装期间关闭防火墙，装完再按端口放行 Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

这三条改完必须重启，尤其是 IPv6 那条，不重启的话某些服务启动时读到的还是老的网络栈配置。

现象五：deploy.bat一运行就退出，或者跑到一半提示权限不足。

原因：CMD 不是以管理员身份打开的，脚本要写注册表、装服务、改系统目录，普通权限第一步就失败。另一种情况是-dcpassword和实际登录密码不一致，脚本连不上服务端，报的错却是「无法读取配置」，很有迷惑性。

解决：右键 CMD 选以管理员身份运行，cd到解压目录再执行；执行前先用浏览器登一次 Deployment Center，确认账号密码没问题。如果仍然失败，看脚本同目录下生成的日志文件，里面有每一步的返回码，比控制台输出详细。

6. 装完怎么验证：deploy.bat 跑完之后要看的四个地方

脚本跑完最后会打一行结束提示，但提示成功不等于环境可用。我一般按下面四步过一遍，全过了才敢把这个环境交给别人用。

第一步看服务。打开服务管理器，把 Teamcenter 相关的服务按名称排一遍，状态应该是正在运行，启动类型是自动。有停在「正在启动」的，多半是数据库连不上或者许可没检出，先去看对应组件的日志。第二步看端口，用netstat确认关键端口在监听：

# 过滤监听状态，确认 Web 层与数据库端口都在 netstat -ano | Select-String "LISTENING" | Select-String ":1433|:8080|:28000"

三个端口分别对应数据库、Web 层和许可服务，缺哪个就回去查哪个组件。第三步验证许可：

:: 确认许可服务能正常检出 feature lmutil lmstat -c 28000@tc2406app -a

输出里 feature 后面跟着Users of xxx: (Total of N licenses issued)就算正常，如果显示Cannot connect to license server，先看许可服务是不是被防火墙拦了。第四步用 Active Workspace 客户端实际登录一次，能进到主界面并且打开一个数据集，才算真的通。只看服务全绿是不够的——我遇到过服务全在跑、登录却一直转圈的，最后查出来是 Web Tier 的配置里主机名写成了短名。

这套流程我走过太多次翻车，从那以后每次部署完都强制自己把这四步走完再宣布结束，不再凭一句「脚本执行成功」就交差。安装这件事，后悔药基本没有，能做的就是把验证做在前面。希望帮到你。

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