AWC2406 Windows部署：deploy.bat生成与复现

简介面向Teamcenter实施与运维人员的AWC2406安装参考文档聚焦借助Deployment Center完成部署这一典型场景适合需要搭建测试或交付环境、梳理安装流程与关键配置项的中级技术人员也可供熟悉Teamcenter基础架构、希望补全AWC部署知识体系者参考。资源包共1个docx文件约4.67MB以图文笔记形式组织围绕环境准备、JDK与许可及数据库服务、安装介质入库、环境创建、应用程序与组件配置、部署脚本生成等环节展开对主机名替换、密码字符限制、介质添加失败时的日志排查位置等易错点也作了提示。文档还涉及Active Workspace Client、Gateway、Corporate Server、Database Server等组件的配置核对便于读者按模块检查配置完整性与部署条件。目前已有313人学习可作为安装前的流程预读、部署过程中的自查清单以及复现问题现场时的参考材料。1. 一台干净的 Windows 主机怎么把 AWC2406 装成一条能复现的流水线拿到 AWC2406 介质那天我先看到的是一张纸改主机名、关防火墙、禁 IPv6、装 JDK17.0.3、装 License Server、装 SQL Server 2019然后打开 Deployment Center 把介质塞进存储库。老版本靠人肉对着文档敲错一步就回滚重来2406 把大半动作收进了 Deployment Center下称 DC你点的是组件和选项它最后吐给你一个 deploy.bat。下面这条链路从裸机走到能登录的 Active Workspace前置条件怎么落地、存储库为什么认路径长度、组件顺序为什么不能乱、密码里哪些符号会让你卡在配置页以及脚本生成后怎么用管理员 CMD 把它跑起来。第一次上手 TC2406 的人能照着走装过老版本的人能看到新部署器到底改了什么。2. 地基三件事主机名、IPv6 与 JDK17.0.3 的先后次序DC 生成的安装脚本里主机名会被写死进环境配置、服务地址和一串内部注册信息里。等到脚本跑完再发现机器名不对改名的代价不是重启一次那么简单而是整个环境要做一次重配置。所以顺序必须是先把机器名定死再装任何东西。2.1 主机名与网络栈先定名再关 IPv6安装笔记里被标黑的位置基本都是主机名占位替换成你自己的机器名即可。命名上有几条硬约束值得提前想清楚长度不超过 15 个字符NetBIOS 上限只用字母数字和短横线不要下划线不要用纯数字开头。有些团队习惯用TC2406APP这种带版本号的名字好处是同一网段里几套环境并存时一眼能认出来。改名用管理员 PowerShell 一条命令就够# 修改主机名并立即重启名字先定死再装后续组件 Rename-Computer -NewName TC2406APP -Restart-NewName后面就是最终要写进 DC 环境里的名字-Restart省得你手动再点一次。改完之后开一个新的 CMD 敲hostname回显和预期一致再往下走。这一步不做验证后面所有组件配置都建立在一个错误的假设上。接着处理 IPv6。DC 内部的组件之间靠主机名互相找解析链路里一旦优先返回 IPv6 地址而 SQL Server 和许可服务实际只监听在 IPv4 上表现就是配置页面转圈、超时日志里看不到任何有价值的信息属于典型的黑匣子故障。禁用它是一条注册表:: 禁用 IPv6 相关接口与隧道重启后生效仅在隔离的部署环境使用 reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0xFF /f/v指定值名/t REG_DWORD声明类型/d 0xFF表示禁用全部 IPv6 接口与隧道组件/f免确认覆盖。改完必须重启。防火墙同理DC 组件之间会拉起一堆动态端口逐个放行的工作量远大于临时关闭:: 三个配置文件全部关闭装完再按需恢复 netsh advfirewall set allprofiles state off注意关防火墙和禁 IPv6 只适用于隔离的部署网段。装完验证通过后把防火墙策略按实际开放端口补回去别让这套临时配置留在生产机上。2.2 JDK17.0.3、License Server 与 SQL Server 2019 的安装次序这三者之间不是随便排的。JDK 是 TC 运行时的底座License Server 决定后面组件能不能起来SQL Server 2019 承载 TC 的库。我一般的顺序是 JDK → License Server → SQL Server原因是 SQL Server 安装耗时长、要重启的概率高放在最后不打断前面的配置节奏。JDK17.0.3 装到短路径别用默认的C:\Program Files\Java\...。带空格的路径在后续 bat 脚本里是翻车的常客某些组件拼接命令行时不会给你加引号。装完设两个环境变量:: 机器级环境变量路径不带空格避免脚本拼接时被截断 setx JAVA_HOME C:\Java\jdk17 /M setx PATH %JAVA_HOME%\bin;%PATH% /M/M表示写机器级而不是当前用户级服务账户启动的进程才能读到。这里有个血泪经验setx PATH是把当前 PATH 展开后写回去如果原 PATH 已经接近 1024 字符会被静默截断表现为某些系统命令突然找不到。稳妥做法是先echo %PATH%看一眼长度或者干脆用系统属性面板手动追加一项。设完开新窗口敲java -version能回显 17.0.3 才算过。License Server 装完后要做两件事把许可文件指到位然后确认服务已启动、端口在监听。常见做法是把许可服务器地址配成端口主机名的形式写进环境变量端口用安装时选定的那个。检验方式很土但有效:: 看许可服务进程与端口是否真的起来了 tasklist | findstr /i lmgrd netstat -ano | findstr :28000findstr /i忽略大小写匹配进程名netstat -ano里的-a列全部连接、-n用数字显示端口、-o带出 PID。两条都有回显才说明许可这一层通了否则后面 Corporate Server 起来也会因为拿不到许可直接退出。SQL Server 2019 有两个参数必须在装的时候定死后面改起来很麻烦身份验证模式选混合模式SQL 登录 Windows 登录排序规则用不区分大小写的那套。实例名保持默认装完到配置管理器里确认 TCP/IP 协议是启用的端口用静态端口而不是动态端口否则 DC 那边填连接信息时你没法确定写哪个数字。sa 密码同样避开后面会提到的特殊符号黑名单省得两个地方两套规则对不上。2.3 介质落盘路径长度为什么是硬约束DC 的存储库固定在D:\DeploymentCenter\repository\software。介质解压进去之后的完整路径会被 DC 扫描、索引、写进生成的脚本里任何一环碰到 Windows 的路径长度上限就会失败而且失败信息往往只告诉你添加失败不告诉你为什么。几个实操细节解压工具不要用那种会自动多套一层同名目录的解压完进software看一眼层级应该是software\介质目录\...而不是software\介质目录\介质目录\...。多套一层DC 就扫不到里面的清单文件界面上表现为存储库里空空如也。另一个是目录名本身别太长别在software下面再建2024\Q3\AWC2406\prod这种为了整齐的中间层。盘符也顺手统一。D 盘放存储库和部署脚本C 盘放程序两边不混。后面 deploy.bat 有一个-softwareLocation参数要指回存储库路径路径统一了脚本复用到第二台机器时改的地方最少。3. 把介质塞进存储库DC 的仓库机制与失败排查DC 这一层做的事说穿了就是把人对着文档判断该装什么换成机器扫描介质、按清单算出该配哪些组件。理解这一点很多界面上的怪异行为就有了解释它不是安装程序它是一个配置生成器最终产物是一个压缩包里的 bat。3.1 存储库目录的职责划分装完 DC 之后D:\DeploymentCenter下面几个目录各有分工搞清楚之后排查问题会快很多目录职责出问题时看什么repository\software存放解压后的安装介质介质目录层级是否多套了一层repository\deploy_scripts按环境名生成部署包是否有Env_xxx\install\deploy_XXX.zipwebserver\repotool\logs介质扫描与索引的日志添加介质失败的唯一线索webserver下的应用目录DC 自身服务服务是否启动、端口是否监听介质放进去之后登录 DC在软件存储库页面能看到处于活动状态的介质条目说明扫描和索引都过了。这一步是整个流程里最容易卡住的地方因为它的成功与否完全取决于文件系统状态跟你的操作手法没关系。3.2 添加介质失败日志是唯一入口界面上添加失败这四个字信息量约等于零。真正的线索在D:\DeploymentCenter\webserver\repotool\logs。别在资源管理器里一个个点开用命令按时间排序看最新的那个# 按修改时间倒序列出日志取最新的一个看尾部 Get-ChildItem D:\DeploymentCenter\webserver\repotool\logs -File | Sort-Object LastWriteTime -Descending | Select-Object -First 3 Name, LastWriteTime, Length# 看最新日志的最后 80 行定位扫描中断的位置 Get-Content D:\DeploymentCenter\webserver\repotool\logs\最新的日志文件名 -Tail 80第一段Sort-Object LastWriteTime -Descending加-First 3是为了在多次重试之后还能分辨哪份是刚才那次的Length字段也能帮忙判断正常扫描的日志动辄几十 KB如果最新那份只有几百字节基本就是刚开头就断了。第二段-Tail 80只看尾部因为失败结论通常在最后。日志里高频出现的几类结论对应的处理方式完全不同提示找不到清单或元数据文件回去查目录层级是不是多套了一层提示路径过长或文件无法访问缩短目录名、把介质挪到更靠近根的位置提示权限拒绝确认 DC 服务运行的账户对software目录有读权限。这三类占了绝大多数剩下的是介质本身不完整重新拷贝一次比研究日志划算。3.3 从创建环境到更新选定的软件介质活动之后新建环境在概述里把名字改成有意义的值比如Env_Tc。这个名字会直接变成deploy_scripts下的子目录名也会出现在部署包文件名里所以别用中文、别带空格。然后回到部署软件的页面在可用软件列表里勾选对应的介质点更新选定的软件。这一步是强绑定动作勾了不等于选上必须点更新界面上的已选软件区域出现正确内容才算数。很多人在这里翻车——勾完直接点下一步结果后面组件列表是空的或者显示的是上一次的旧介质。软件绑定正确之后点转至选项把需要的选项勾上保存环境。选项决定了后面组件清单里出现哪些条目比如要不要部署 Active Workspace 那一套、要不要装索引服务。这里的取舍原则很简单不确定就先只勾主链路跑通一次之后再回来加。一次性全勾上中途某个组件配置失败你很难判断是前置条件的问题还是这个组件本身的问题。4. 组件配置的顺序学从 Database Server 到 FSC 的参数面到了组件这一步DC 会把整个安装拆成十几个带状态的条目每个条目单独配置、单独校验全部到 100% 才能生成脚本。界面上的顺序是有依赖关系的不是随便排的。4.1 应用程序选择与转至组件的时机在应用程序页面能添加可用的应用程序选完同样要点更新选定的应用程序再点转至组件。这个更新动作在 DC 里出现了三次软件、应用程序、组件参数本质都是同一件事把界面上的勾选状态提交成配置状态。养成勾完必点更新的习惯能省掉一大半莫名其妙的空列表。组件列表大致是这样一串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)。每个条目后面有个入口能展开更细的配置别嫌麻烦默认值在这套环境里不一定成立。4.2 组件依赖顺序为什么 Database Server 要排在前面配置顺序上Database Server 先做。它要填的是数据库实例、库名、登录账户和密码后面 Corporate Server 起来第一件事就是连这个库。库没配对Corporate Server 的校验就会一直卡在某个百分比上不动界面上也不会告诉你它在等数据库。Corporate Server 之后是 Teamcenter Web Tier (Java EE)再往后是 Active Workspace Gateway 和 Client Builder。FSC 系列FSC、FSC Group、FSC Keys我通常放在 Web Tier 之后配因为它涉及文件存储卷的路径和共享账户需要前面把服务账户确定下来。Indexer 和 Indexing Engine 放最后它们依赖前面已经有一个能连上的库。组件状态的百分比不是进度条是校验通过项的比例。卡在某个数字不动说明有一项硬性检查没过这时候别反复点重试回上一级看具体是哪个字段标红了。DC 在这一点上做得还算厚道展开组件详情能看到逐项检查结果。4.3 密码字符集DC 与 TEM 的两套规则这是整条链路上最容易让人卡住半小时的地方。DC 里配置 Database Server 和 TC 的密码时不允许出现特殊符号而 TEM 里是允许的。两套规则并存你在一个地方设了带感叹号的密码另一个地方就会拒绝。被 DC 明确拒绝的字符包括!$%^:;._(){}。注意里面连下划线和点号都在列这两个是很多人下意识会用的分隔符。稳妥策略是密码只用大小写字母加数字长度给够别在这套环境里追求符号复杂度。位置是否允许特殊符号建议做法DC 中 Database Server 密码不允许纯字母数字长度 12 位以上DC 中 TC 账户密码不允许同上与其他系统密码区分开TEM 中密码允许按所在环境的密码策略执行SQL Server sa 密码建议同样避开避免两套规则对不上注意这条限制只作用于 DC 生成配置的阶段。等脚本跑起来、服务装好之后再去改系统账户密码是另一回事别把两个场景混为一谈。4.4 各组件的关键参数怎么填Database Server 这块实例名和端口要和 SQL Server 配置管理器里看到的一致如果用默认实例就填主机名命名实例要写主机名\实例名。登录账户用 SQL 账户而不是 Windows 账户跨机器部署时省掉一堆委派配置。Corporate Server 要填的是服务账户和安装路径。服务账户建议用专门建的一个本地管理员账户别直接用 Administrator后面排查某个服务起不来时账户是不是权限不足这个变量能排除掉一大块。Active Workspace Gateway 和 Client Builder 涉及访问地址这里填的主机名必须是客户端能解析到的名字不是localhost。填localhost装完本机自测能通换台机器打开就 404这类问题在生产环境里排查成本极高。FSC 的文件卷路径给一个独立磁盘分区别和安装目录混在一起。共享账户的权限要提前配好配置阶段校验会实际去读写一次权限不够当场就会红。全部组件到 100% 之后点转至部署再点生成安装脚本。生成成功后界面会给出部署说明实际的部署包在D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install\deploy_XXX.zip。5. 避坑清单五条踩过的坑与对应解法这一节里每条都是现象 → 原因 → 解决的结构按遇到频率排序。现象一软件存储库里看不到刚放进去的介质或者条目一闪就没了。原因基本是目录层级不对。解压工具多套了一层同名目录DC 扫描时在software\介质目录下找不到预期的清单文件扫描直接判失败界面上什么都不显示。另一种可能是路径太长索引过程中断。解决方式是进software目录看实际层级把介质内容上提到正确的位置同时把中间层目录名缩短让从盘符到清单文件的总长度控制在合理范围。改完不用重启 DC重新在界面上执行一次添加即可。现象二组件配置到 Database Server 一直过不去提示连接或认证失败。原因有两个常见来源。一是密码里带了特殊符号被 DC 的字符集规则截断或者直接拒绝你输入的和它实际保存的不一致二是 SQL Server 只开了 Windows 身份验证或者 TCP/IP 协议没启用。解决方式是先把密码改成纯字母数字重试仍然失败就去 SQL Server 配置管理器确认协议启用状态和端口再用同样的账户密码从命令行连一次把问题定位在数据库侧还是 DC 侧。现象三deploy.bat 双击一闪而过或者在管理员 CMD 里报找不到 Java。原因是脚本没有以管理员权限运行或者它继承到的JAVA_HOME指向了带空格的路径又或者环境变量是在当前用户级设置的、提权后的进程读不到。解决方式是用以管理员身份运行打开 CMDcd到解压目录先敲java -version和echo %JAVA_HOME%各看一次输出正确再执行脚本。变量如果是用户级的用setx /M重设一遍然后关掉所有 CMD 窗口重开。现象四环境里已选软件显示的是旧介质更新之后组件列表还是空的。原因是勾选之后没点更新选定的软件就跳走了配置状态没提交。解决方式是回到部署软件页面重新勾选、重新点更新确认已选软件区域的内容与预期一致再点转至选项。这个坑在换了介质版本之后特别容易撞上因为界面上旧条目还在看起来像是已经选好了。现象五脚本跑完服务列表里服务都在但 AWC 页面打不开报 503 或超时。按顺序查三层先看 Teamcenter Web Tier 和 FSC 相关服务是否真的处于运行状态不是启动类型自动而是正在运行再看主机名解析从客户端ping主机名确认解析到的是这台机器的 IPv4 地址而不是别的最后看 Web 服务日志里是连不上后端还是连不上库。这三层覆盖了绝大多数安装后不可用的情况而且检查成本都很低先做便宜的检查。6. 从 deploy_XXX.zip 到验证通过脚本落地与复现技巧部署包的位置是固定的D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install\deploy_XXX.zip。把它解压到一个和存储库无关的目录比如D:\deploy_run。别解压在存储库目录里面原因是部署过程中会往存储库写东西两边混在一起之后出问题你分不清是脚本产生的还是扫描产生的另外解压路径越短越好长路径在这个环节同样会咬人。解压完用管理员身份打开 CMD进到解压路径执行:: 以管理员身份运行的 CMD 中执行路径按实际解压位置调整 cd /d D:\deploy_run deploy.bat -dcusernamedcadmin -dcpassworddcadmin -softwareLocationD:\DeploymentCenter\repository\software三个参数的含义-dcusername和-dcpassword是连接 DC 用的账户脚本会拿它回去读环境配置所以这个账户必须有对应环境的读权限换成别的账户大概率在第一步就失败-softwareLocation指向存储库的software目录脚本按环境配置里的记录去这里取实际的安装文件安装。三个参数都不能带引号包裹路径里也不要出现空格这也是前面反复强调短路径、无空格的原因。参数里最容易出错的是-softwareLocation。写成D:\DeploymentCenter\repository少一级或者写成磁盘映射的网络路径都会导致脚本跑到中途找不到安装包。判断方式很简单执行前先dir D:\DeploymentCenter\repository\software看一眼有内容路径就是对的。脚本跑起来之后不要盯着窗口看它会调起多个子安装程序窗口安静几分钟是正常的。真正的进度在日志里安装过程中产生的日志会落在解压目录和系统临时目录下出问题时优先看解压目录里新生成的日志文件尾部通常直接写着哪个组件失败了。装完之后按下面这张表逐项验证比凭感觉判断靠谱验证项命令或动作期望结果服务状态sc query逐个查关键服务全部 RUNNING端口监听netstat -ano | findstr :端口对应 PID 在监听主机名解析客户端ping 主机名解析到本机 IPv4许可许可服务进程与端口检查进程存在、端口可连数据库用配置账户连一次目标库连接成功、表结构存在前端浏览器打开 AWC 访问地址能到登录页表格里前两项是机器侧的自检后四项是从使用方视角的验证。我的习惯是四项全过才算装完缺一项就先记下来别急着交环境——尤其是主机名解析这一项本机自测永远是通的只有在另一台机器上打开浏览器才能暴露问题。还有一个复现技巧值得单独说整套流程跑通之后把D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install下的部署包连同当时的环境配置一起归档标上主机名和日期。第二次装同样的环境时很多配置项可以直接对照着填能省掉大量试错更重要的是当某台机器装出问题时你手上有一份已知能跑通的参照物比对配置差异比从零排查快得多。从那以后我每次碰这类部署器都强制先走一遍前置条件核对 → 介质落盘检查 → 组件逐项到 100% → 脚本管理员执行 → 六项验证这条固定路径一步不跳。跳过的那一步最后总会以别的方式还回来。希望帮到你。本文还有配套的精品资源点击获取