简介面向 Teamcenter 实施与运维人员的中文安装参考文档聚焦使用 Deployment Center 部署 AWC2406 的完整流程适合需要搭建测试环境或对照官方文档排查配置问题的初中级工程师。压缩包仅含 1 个 docx 文件大小约 4.67MB以图文步骤和要点批注整理安装前的主机名、防火墙与 IPv6 设置JDK、License Server、SQL Server 等依赖准备以及存储库介质添加、环境与组件配置、安装脚本生成等关键环节。内容还提示了日志路径、密码特殊符号限制等易错点便于读者在实操时快速定位问题、减少反复试错。目前已有 312 人学习可作为 AWC2406 部署过程的随身查阅资料。1. 一台刚装好的 Windows ServerDeployment Center 装 AWC2406 之前先把四件事做完用 Teamcenter Deployment Center 装 AWC2406真正让人返工的从来不是点鼠标那几步而是点开它之前的环境底子。主机名还带着默认随机串、hosts 里只有一行 127.0.0.1、防火墙开着、IPv6 还活着——这套环境跑起来会出现各种说不清的症状许可服务连不上、组件配到一半卡住、部署脚本执行到中间莫名退出。机器得是干净的 Windows Server账号有本地管理员权限装完系统别急着装别的先把这四件事处理干净。第一次独立搭 AWC2406 的人以及装过一次被半路报错劝退的人都值得在这里多花二十分钟。2. 底座三件套JDK 17.0.3、License Server 4 与 SQL Server 2019 的安装落地Deployment Center 只是个“生成配置和脚本”的壳子它生成的脚本最终要落在一台有 Java、有许可、有数据库的机器上跑。这三样东西的安装顺序我一般固定为 JDK → License Server → SQL Server原因是 JDK 装完能立刻验证许可服务依赖主机名和 MAC 地址主机名没定死之前装它等于白装SQL Server 最重、耗时最长放最后不打断前面的节奏。顺序反了不会立刻报错但会在后面排查时让你多怀疑一轮这种玄学账最不划算。2.1 JDK 17.0.3装在哪JAVA_HOME 怎么落AWC2406 这条线要求 JDK 17.0.3别拿机器上现成的 JDK 8 或者 JDK 11 凑合Deployment Center 生成的脚本里对 java 路径是有预期的。安装方式我倾向于用 zip 包解压而不是跑 exe 安装向导理由很实际解压式安装不写注册表、不往C:\Program Files里塞东西出问题直接删目录重来也不用担心卸载残留。解压目标目录两个硬性要求路径不含空格、不含中文。D:\Java\jdk-17.0.3这种就很好C:\Program Files\Java\jdk-17.0.3虽然也能跑但后面 Teamcenter 的一些批处理脚本对带空格的路径处理得并不优雅能不踩就不踩。# 以管理员身份打开 PowerShell先确认当前机器上没有别的高版本 JDK 抢路 Get-Command java -ErrorAction SilentlyContinue | Select-Object Source # 写入系统级Machine环境变量而不是只写当前用户 [Environment]::SetEnvironmentVariable(JAVA_HOME, D:\Java\jdk-17.0.3, Machine) # 把 %JAVA_HOME%\bin 追加到系统 PATH 末尾 $oldPath [Environment]::GetEnvironmentVariable(Path, Machine) [Environment]::SetEnvironmentVariable(Path, $oldPath ;%JAVA_HOME%\bin, Machine)这里几个点值得说清楚。Machine表示写系统级变量写User只有当前登录账户能看到而部署脚本是以管理员 CMD 跑的多数情况下能读到但服务账号未必读得到所以统一写 Machine 更稳。PATH 里写的是%JAVA_HOME%\bin而不是展开后的绝对路径这样以后换 JDK 小版本只改 JAVA_HOME 一处就够了。另外如果Get-Command java查出来机器上已经有一个旧 JDK 在 PATH 前面务必把旧的 bin 挪到后面或者直接删掉否则java -version显示的版本和 JAVA_HOME 对不上排查起来极其迷惑。环境变量写完必须新开一个 CMD 窗口验证老窗口读的是旧环境。# 新开的管理员 CMD 里执行 echo %JAVA_HOME% java -version期望输出是openjdk version 17.0.3开头的那一行如果不是 17.0.3就是 PATH 顺序问题或者变量没生效必要时重启一次机器让服务管理器重新加载环境块。这一步没验通就别往下走后面 Deployment Center 生成脚本、执行部署都会用到 java早发现比晚发现省一小时。2.2 License Server 4许可服务先跑通再谈部署Siemens License Server 4 装完是一个后台服务加一套 lmtools 管理界面。安装本身没什么坑坑都在 license 文件上文件里的 SERVER 行要写当前主机名和网卡 MAC 地址主机名必须和hostname命令输出完全一致大小写不敏感但拼写必须对MAC 地址取的是启用中那块物理网卡的。虚拟机克隆出来的机器最容易在这里翻车——主机名改了许可证文件里还是模板里的旧名字。我一般的做法是先把主机名定死再装许可服务# 改主机名重启后生效命名建议全小写、无下划线、不超过 15 字符 Rename-Computer -NewName tc2406 -Force Restart-Computer重启回来后确认hostname输出是tc2406再把许可文件里的 SERVER 行改成SERVER tc2406 MAC地址 28000。端口 28000 是这套许可服务常见的默认端口如果你环境里已经有别的许可服务占了它换一个没被占用的端口但要记住Deployment Center 里 Licensing Server 组件配置时填的端口必须和这里一致两边对不上后面组件配置阶段会卡在许可校验上。服务注册和启动走 lmtools 的图形界面Config Services 页指定 lmgrd 路径、license 文件路径、debug log 路径Save ServiceStart/Stop/Reread 页先 Stop 再 Start。命令行验证更直接# lmutil 通常在许可服务安装目录下用它查服务状态 lmutil lmstat -a -c 28000tc2406输出里能看到License server UP和具体的 feature 列表就说明许可这层通了。如果报Cannot connect to license server八成是服务没起来、端口被占、或者 hosts 里主机名解析不到本机——这也是为什么第 1 章要先处理 hostsC:\Windows\System32\drivers\etc\hosts里加一行127.0.0.1 tc2406能省掉很多解析类报错。2.3 SQL Server 2019实例、排序规则与混合认证SQL Server 2019 是这一轮里耗时最长的一步安装向导走下来的关键选项只有三个但每一个选错都要重装。第一是实例。默认实例还是命名实例都行但如果机器上已经有别的 SQL 实例建议用命名实例避免冲突比如TC2406。实例名要记下来后面 Database Server 组件配置时要填。第二是排序规则。Teamcenter 这套对排序规则敏感常见做法是选SQL_Latin1_General_CP1_CI_AS装完再改的代价很大要重建实例。向导里在“服务器配置”之前的那一页可以改别一路下一步跳过去。第三是身份验证模式。必须选“混合模式”并设置 sa 密码。这里有个连锁约束——Deployment Center 里配置 Database Server 时填的密码不允许包含特殊符号所以 sa 密码最好从一开始就用纯字母加数字的组合省得后面在 DC 界面里填不进去还要回来改数据库密码。装完之后还要做两件事启用 TCP/IP 协议、确认端口。-- 用 sqlcmd 连上实例后执行确认三件事版本、排序规则、是否混合认证 SELECT SERVERPROPERTY(ProductVersion) AS ver, SERVERPROPERTY(Collation) AS collation, SERVERPROPERTY(IsIntegratedSecurityOnly) AS windows_only;windows_only返回 0 表示混合认证已开启返回 1 就是只允许 Windows 认证得回 SQL Server 配置管理器里改回来重启服务。排序规则那一行如果不是SQL_Latin1_General_CP1_CI_AS趁现在数据还没进去重装实例是最省事的选择。TCP/IP 在“SQL Server 配置管理器 → 网络配置 → 协议”里启用然后在 IP 地址页把 TCP 端口固定成 1433把动态端口那一栏清空重启 SQL Server 服务。因为我们第 1 章已经把防火墙关了端口连通性不用额外开规则# 确认 1433 在监听 Get-NetTCPConnection -LocalPort 1433 -State Listen | Select-Object LocalAddress, LocalPort到这一步JDK、许可、数据库三个底座都通了。这时候再装 Deployment Center 2406它才能在配置组件阶段顺利探测到许可服务和数据库实例否则你会以为是 DC 的问题实际是底下没准备好。3. 介质入库Deployment Center 2406 的存储库路径与添加动作Deployment Center 装好之后的第一件事不是急着创建环境而是把 AWC2406 的安装介质“喂”给它。这一步看着最没技术含量实际上是整套流程里最容易失败的一步而且失败现象特别模糊——界面上就一句“添加失败”什么都不告诉你。我踩过的坑基本都集中在路径长度和解压完整性上。3.1 解压路径为什么越短越好Deployment Center 的软件存储库默认位置是D:\DeploymentCenter\repository\software介质解压到这个目录下。项目正文里特意强调“解压后的介质路径要尽量短”这句话不是客套是血泪经验。原因在 Windows 的路径长度限制。传统 Win32 API 的 MAX_PATH 是 260 个字符虽然新版本 Windows 可以通过注册表开关放开长路径但 Deployment Center 内部调用的解压和扫描工具未必都支持。AWC2406 的介质目录层级本来就深...\repository\software\awc2406\...\...\...再加几层很容易在中间某个文件上超限表现就是解压到一半报错或者解压完了但扫描时漏文件——你看着目录结构是完整的实际少了几个 jar后面添加介质就是失败。我一般这么解压# 用 7-Zip 解压输出目录保持一级避免深层嵌套 C:\Program Files\7-Zip\7z.exe x D:\media\AWC2406.zip -oD:\DeploymentCenter\repository\software\awc2406 -yx表示按原目录结构解压不是把文件全铺平-o后面紧跟输出目录、中间不能有空格-y表示所有确认一律 yes适合批处理。解压目标只保留一层awc2406不再往里面套Teamcenter\AWC\2406\full\这种自造目录这是控制路径长度的关键动作。另外解压工具尽量别用 Windows 自带的资源管理器右键解压。它对大文件、深路径、长文件名的处理不如 7-Zip 稳定而且失败时给的信息极少。介质动辄几个 G解压一次要十几分钟用错工具等于白等一轮。还有一点解压完成后顺手确认一下磁盘剩余空间。存储库目录建议留出介质体积两倍以上的余量因为 Deployment Center 在生成部署脚本时会在repository下再产生一批文件空间不够时它的报错同样很含糊。3.2 添加介质与 repotool 日志的正确读法介质解压到位后登录 Deployment Center 控制台进入软件存储库页面正常情况下能看到刚加进去的介质条目状态是活动的。如果没看到或者添加过程中报错第一站就是日志# 先按时间倒序列出最近的日志文件找到本次操作对应的那一个 Get-ChildItem D:\DeploymentCenter\webserver\repotool\logs | Sort-Object LastWriteTime -Descending | Select-Object -First 3 Name, LastWriteTime, Length # 再从中捞出错误行比从头读整个日志快得多 Select-String -Path D:\DeploymentCenter\webserver\repotool\logs\*.log -Pattern ERROR|Exception|not found | Select-Object -Last 20repotool这个目录名对应的就是存储库扫描工具添加介质的动作本质上是它在遍历目录、识别介质类型、写元数据。日志里最常见的三类错误一类是文件找不到解压不完整、文件名被截断一类是版本标识识别不出来介质包本身不完整或者不是 DC 认的格式一类是权限问题DC 服务账号对存储库目录没有读权限。如果是权限问题把存储库目录的读取权限显式给到 DC 的服务运行账号然后重启 Deployment Center 相关服务再试。别图省事直接给 Everyone 完全控制虽然能通但后面出了别的问题你会分不清是不是权限放太宽导致的。介质状态变成“活动”之后不要立刻创建环境。先在存储库页面里点开介质详情看一眼版本号和组件清单确认它确实是 2406、确实包含你需要的那些组件。介质版本看错、装到一半发现少组件的情况我在早期环境里遇到过不止一次那时候只能从头再来。4. 环境与组件配置从 Env_Tc 到所有组件 100%介质入库之后Deployment Center 里的操作就进入了三段式先建环境再选软件和应用程序最后逐个组件填参数。这个顺序不能乱因为后一步的可选项是前一步决定的。三段都走完、所有组件状态到 100%才能生成安装脚本。4.1 创建环境与 Env_Tc 这个命名在 Deployment Center 里创建环境进入环境后在“概述”页可以改环境名称。示例里用的是Env_Tc我建议就按这个风格命名短、只含字母数字下划线、能一眼看出用途。环境名不是随便取的标签它会变成部署脚本的目录名。生成脚本后部署包的位置就是D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install——环境名直接嵌在路径里。所以两点要注意一是名字里别带空格和特殊字符否则后面在 CMD 里敲路径要加引号容易出错二是一旦开始配置组件就别再改环境名改完之后旧的deploy_scripts目录还在新目录是空的你可能会拿着上一轮的脚本去部署。创建完环境先别急着往下点回到部署软件页面在可用软件列表里选中刚才入库的那份介质点“更新选定的软件”。这一步是把介质的内容“绑定”到当前环境没做这一步后面的应用程序和组件列表都是空的。4.2 应用程序把介质内容变成可部署清单软件绑定好之后进“应用程序”页这里列出的是介质里包含的所有可部署应用程序。按需勾选然后点“更新选定的应用程序”再点“转至组件”。这一步的取舍在于勾得越多后面要填的组件参数越多出错面越大勾得太少装完发现缺功能还要重来一轮。我的建议是第一次搭环境时按标准组合全勾上——Active Workspace 相关、Corporate Server、Database Server、FSC 系列、Indexer、Licensing Server、Microservice Node、Server Manager、Web Tier 这些先把完整链路跑通再考虑裁剪。裁剪是优化阶段的事不是首次安装该做的事。更新完应用程序后回到“已选软件”确认一眼内容对不对。列表里如果出现重复条目或者版本号不一致说明前面介质入库时有残留回存储库页面清掉重新加一次比在这里硬着头皮往下走划算。4.3 组件逐项配置与密码字符红线组件页是整套流程里工作量最大的地方。要点是“按顺序”配置——每个组件点进去能看到更详细的配置信息很多字段的默认值是从前一个组件推导出来的跳过顺序去填后面的会拿到一堆空值或者错误的默认值。常见的组件和它们负责的事大致是这样组件配置重点Active Workspace Client Builder客户端构建参数与 Web Tier 的地址要对齐Active Workspace Gateway网关地址与端口后续客户端访问入口Corporate Server主服务参数、实例目录、TC 数据目录Database Server数据库实例名、端口、DBA 账号与密码FSC / FSC Group / FSC Keys文件存储卷、卷组、密钥路径要绝对路径Indexer / Indexing Engine索引服务地址与索引库位置Licensing Server许可服务主机与端口必须和 2.2 里配的一致Microservice Node微服务节点地址多机部署时要区分Server Manager / Cluster Configuration服务管理器与集群参数单机也要填Teamcenter Web Tier (Java EE)Web 层部署参数依赖前面所有组件配置过程中有一条硬性约束也是我见过最多人栽的地方注意在 Deployment Center 里配置 Database Server 以及 Teamcenter 的密码时不允许出现! $ % ^ : ; . _ ( ) { }这些特殊符号TEM 里是允许的。这条限制的杀伤力在于它不在显眼位置提示你按公司密码规范填一个带!和的强密码界面上可能只是保存失败或者某个字段变红也可能一路保存成功、到生成脚本或执行部署时才炸。稳妥做法是DC 里所有密码字段统一用“大小写字母 数字”的组合长度拉够特殊符号一个都不放。等环境跑起来之后再去数据库和 TC 里按自己的规范改密码那时候就不受 DC 的约束了。每个组件填完点保存回到组件列表看状态百分比。全部 100% 之后页面上的“转至部署”才真正可用。4.4 生成安装脚本所有组件状态到 100%点“转至部署”再点“生成安装脚本”。这一步 Deployment Center 做的是把所有配置渲染成一套可执行的部署包包括响应的属性文件、批处理入口和部署说明。生成成功后会给出部署说明同时磁盘上出现部署包D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install\deploy_XXX.zip这个XXX是 DC 自动生成的标识别手动改文件名。拿到包之后不要就地解压复制到一个短路径下再解比如D:\deploy\install。原因和第 3 章一样路径长度。部署包里有大量深层目录就地解压在repository\deploy_scripts\Env_Tc\install\下面再展开很容易踩到路径上限。5. 避坑记录五个在 Deployment Center 里翻车的现场这一章是我自己遇到和帮别人处理过的典型问题按“现象 → 原因 → 解决”记下来。这些问题有个共同点界面上给的信息都不足以定位必须自己去翻日志或者翻目录。5.1 介质添加一直失败界面只说“添加失败”现象介质已经解压到repository\software下目录看着完整但在软件存储库里点添加等几分钟后报失败没有任何细节。原因绝大多数是解压路径太深导致部分文件没解出来或者解压工具在中途静默跳过了几个长路径文件。少数情况是 DC 服务账号对存储库目录没有读权限。解决先把解压目标缩短一层重解压比如从...\software\awc2406\teamcenter\...改成...\software\awc2406重解压后比对文件总数和介质包里的条目数对得上再试。仍然失败就去D:\DeploymentCenter\webserver\repotool\logs找最新日志按 ERROR 行定位是文件缺失还是权限问题权限问题就给 DC 服务账号加读取权限并重启服务。5.2 组件状态卡在 90% 左右不动现象某个组件填完保存状态一直是 90% 或者 95%点“转至部署”按钮是灰的。原因组件里还有必填项没填或者填了但格式校验没通过。DC 不会把每个未通过的字段都高亮出来尤其是嵌套在折叠区域里的字段。解决点进该组件逐个标签页展开看重点检查路径类字段是否绝对路径、目录是否存在、端口类字段是否和已配置的其他组件冲突、以及从上一个组件继承下来但没同步更新的默认值。改完保存再看状态一次改一个字段别同时改三处否则你不知道是哪一处起的作用。5.3 密码填了特殊符号保存看似成功但部署阶段报错现象Database Server 的密码用了带!和的强密码界面保存没报错等到执行deploy.bat时脚本中途退出。原因DC 对 Database Server 和 TC 的密码有字符集限制特殊符号不被接受但校验发生在渲染脚本阶段而不是保存阶段所以前面看不出来。解决把所有 DC 里的密码字段改成纯字母数字组合重新生成脚本。已经生成过的旧脚本目录不要复用重新生成一个新包解压到新目录再执行混用会导致配置和脚本不一致。5.4 改了环境名部署脚本跑到旧目录去了现象环境从Env1改名成Env_Tc重新生成脚本后去deploy_scripts\Env_Tc\install找不到包或者找到的是旧的。原因环境名在生成脚本时被固化进路径改名不会迁移已有的deploy_scripts子目录旧目录仍然存在并且可能被误用。解决改完环境名后先把repository\deploy_scripts下对应的旧目录整个移走或删掉确认没有要保留的包再重新生成。执行部署前先看一眼包的修改时间确认是刚生成的那一份。5.5 双击 deploy.bat 一闪而过什么都没发生现象解压完部署包双击deploy.bat黑窗口闪一下就关了日志目录里也没有新内容。原因deploy.bat需要管理员权限并且需要带参数运行。双击的方式既没有提权也没有传参脚本走到参数解析就退出了。解决右键“以管理员身份运行”打开 CMDcd到解压目录再带参数执行deploy.bat。如果还是闪退先在该 CMD 窗口里不加参数跑一次看它的用法提示确认参数名拼写另外确认 CMD 的工作目录确实是解压后的install目录路径敲错也会立刻退出。6. 从 deploy.bat 到验证怎么确认这套 AWC2406 真的跑起来了部署包解压到短路径后用管理员权限打开 CMD进到解压目录执行REM 必须以管理员身份运行 CMD否则脚本无法注册服务和写系统目录 cd /d D:\deploy\install REM -dcusername / -dcpassword 是登录 Deployment Center 的账号不是 Windows 账号 REM -softwareLocation 指向存储库里的 software 根目录必须和 DC 中配置的一致 deploy.bat -dcusernamedcadmin -dcpassworddcadmin -softwareLocationD:\DeploymentCenter\repository\software三个参数里最容易搞错的是-softwareLocation。它要的是repository\software这一层不是某一份介质的具体目录也不是repository本身。填错的话脚本在准备阶段就会失败报找不到介质。另外把 DC 的明文密码写在命令行里它会留在 CMD 历史和一些日志文件中装完之后记得把 DC 的管理员密码改掉这是我一直保持的习惯。脚本执行时间不短中间会滚动大量输出不要因为长时间没动静就 CtrlC。真正的进度和错误都写进日志出问题时去看部署目录下的 log 子目录按时间找最新的那份从最后一条 ERROR 往回读。跑完之后别急着打开浏览器先做三层验证。第一层看服务# Teamcenter 相关服务应该都是 Running重点看 FSC、Indexer、Pool Manager、Web Tier Get-Service | Where-Object { $_.DisplayName -match Teamcenter|FSC|Index|Pool } | Select-Object Name, DisplayName, Status第二层看端口和许可1433 在监听、28000 能连、Web 层端口在监听再用lmutil lmstat确认许可服务认得出这台机器。第三层才是打开浏览器访问 Active Workspace 登录页用部署时配置的管理员账号登进去随便打开一个卷、上传一个小文件再下载回来——这一步是在验证 FSC 的读写链路光能登录不算跑通很多人就是卡在能登录但传不了文件上。从那以后我每次装完都是这个顺序服务、端口、许可、登录、传文件五步全过才算这套环境交付。中间任何一步跳过后面出问题都要多怀疑一轮。这份 Deployment Center 2406 的安装流程和参数配置整理成了可对照的笔记照着走能少绕不少弯希望帮到你。本文还有配套的精品资源点击获取