企业官网建设流程全解析

简介：面向Teamcenter实施与运维人员的一份AWC2406安装参考文档，聚焦使用Deployment Center完成部署的环境准备、介质管理、环境与组件配置及脚本生成等关键环节，适合需要搭建测试环境、对照排查安装问题或梳理部署流程的初中级工程师。压缩包共1个docx文件，约4.67MB，以图文笔记形式整理安装要点与配置说明，目录按阶段展开，便于随查随用。内容覆盖主机名与网络设置、JDK17.0.3、Siemens License Server和SQL Server2019等前置服务，Deployment Center存储库介质添加与日志定位，环境创建、软件选择、应用程序与组件顺序配置，以及Database Server和TC密码特殊字符限制、TEM差异等易错点；同时给出部署包生成、解压与deploy.bat运行参数示例，并提示介质路径、日志目录和配置状态检查等排错线索，可帮助读者理解部署链路并定位常见失败原因。已有312人学习，适合作为AWC2406部署的随查参考。

1. Deployment Center 2406 装 AWC2406：真正卡人的是环境而不是安装包

装 AWC2406 这件事，很多人以为难在 Teamcenter 本体，实际卡住进度的是 Deployment Center 2406 这一层：介质解压路径带中文、入库日志藏在 repotool\logs 里没人看、环境建好后组件状态在 90% 停住、Database Server 和 TC 的密码里混进一个下划线就直接配置失败。这篇按我自己走一遍的顺序拆开：hosts 主机名怎么对、防火墙和 IPv6 为什么要在装 JDK 之前关、JDK17.0.3 与 License Server、SQL Server 2019 的先后顺序、介质丢进存储库后去哪翻日志、Env_Tc 里 15 个组件按什么顺序配、deploy.bat 三个参数各管什么。适合第一次碰 AWC2406 的部署人员，也适合装到一半卡住要回头查错的人。

2. 前置底座：hosts、防火墙、IPv6 与 JDK17 的固定动作

在点开 Deployment Center 之前，先把机器底座打平。这一层看起来是“装 JDK、关防火墙”这类杂活，实际上主机名对不上、IPv6 没关、JDK 版本偏一点，都会在后面组件配置阶段以完全不相干的形式报出来。我一般把这一段当成一次性的体检，做完再进安装器。

2.1 主机名与 hosts 映射：黑色笔记里最容易漏的一行

黑色笔记里覆盖的主机名，指的是安装文档或部署计划里写死的那几个 hostname，改成自己机器的名字。Deployment Center 生成脚本时会把这些名字灌进配置文件，装完再改成本很高。

常见做法是两台机器：一台放应用（Teamcenter 服务、AWC Gateway），一台放数据库（SQL Server）。hosts rides 里把两台都写上，应用机指向数据库机，数据库机指回应用机。

# 管理员 PowerShell 执行；先备份再追加 Copy-Item C:\Windows\System32\drivers\etc\hosts C:\Windows\System32\drivers\etc\hosts.bak # 把 IP 和主机名换成你自己的 Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value "10.20.30.40 tc-node01" Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value "10.20.30.41 tc-db01"

这段操作做两件事：备份原 hosts，追加两条静态映射。参数上，10.20.30.40 是应用机地址，tc-node01 是应用机主机名，tc-db01 是数据库机。主机名只用小写字母、数字和短横线，不要下划线，也不要带中文——Windows 主机名对下划线兼容性差，后面 Web Tier 解析会翻车。

改完用ping tc-node01验证，返回的是 10.20.30.40 而不是 127.0.0.1 才算生效。如果开了 IPv6 且解析优先走 v6，ping 可能返回 ::1，这就是下一节要关 IPv6 的原因之一。

还要确认计算机名本身：右键此电脑 → 属性 → 重命名，把机器名改成和 hosts 里一致的值。主机名和 hosts 对不上时，License Server 和 Microservice Node 会报无法解析主机，但报错位置往往在组件状态里，不直接说主机名。三处名字（计算机名、hosts、部署方案）保持统一，是后面所有组件配置的前提。

2.2 防火墙与 IPv6：为什么要先关，而不是装完再补

Deployment Center 在配置组件时会做端口探测和远程调用，防火墙拦一个端口，界面上只显示某组件状态不动，日志里才看得到连接超时。IPv6 的问题是解析优先级：机器同时有 v4 和 v6 时，某些服务会先尝试 v6 地址，而 Teamcenter 各组件之间默认按 v4 通信，结果就是 AWC Gateway 连不上 Corporate Server。

关闭防火墙：

# 三个配置文件一起关，仅限内网部署环境；上线后按端口白名单再开 Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False Get-NetFirewallProfile | Select-Object Name,Enabled

Set-NetFirewallProfile一次改三个 profile，第二条命令回读状态，Enabled 全为 False 才算关掉。注意这是内网安装阶段的临时动作，装完按实际端口开白名单，不要长期裸奔。

禁用 IPv6 绑定：

# 禁用所有网卡的 IPv6 绑定；执行后网络会短暂抖动 Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6 Get-NetAdapterBinding -ComponentID ms_tcpip6 | Select-Object Name,Enabled

-Name "*"表示所有网卡，ms_tcpip6是 IPv6 协议组件的固定 ID。回读时 Enabled 为 False 表示已禁用。如果只想禁某块网卡，把*换成网卡名。部分环境禁用后需要重启网卡或重启机器才彻底生效。

这两步的顺序有讲究：先关防火墙再禁 IPv6，因为禁用 IPv6 时网络栈会重建，防火墙规则可能被重置。我一般先跑防火墙命令，回读确认，再跑 IPv6，最后重启一次机器，避免半生效状态。重启完再回读一遍两个状态，确认没有被系统还原。

2.3 JDK 17.0.3、License Server 与 SQL Server 2019 的安装顺序

JDK 必须第一个装，因为 License Server 和 Deployment Center 自身都依赖 JAVA_HOME。版本锁在 17.0.3，不要用 17 的其他小版本替换——Teamcenter 2406 对 JDK 小版本有校验，装错了 Deployment Center 启动日志里会报 UnsupportedClassVersionError。

安装时记住路径，常见落在C:\Program Files\Java\jdk-17.0.3。装完设环境变量：

# 设置 JAVA_HOME 并追加到 PATH；路径按实际安装位置改 [Environment]::SetEnvironmentVariable("JAVA_HOME", "C:\Program Files\Java\jdk-17.0.3", "Machine") $oldPath = [Environment]::GetEnvironmentVariable("Path", "Machine") [Environment]::SetEnvironmentVariable("Path", "$oldPath;%JAVA_HOME%\bin", "Machine")

Machine级别写入，所有用户生效。设置完重开一个终端，java -version应输出 17.0.3；如果还是旧版本，检查 PATH 里是否有更靠前的 Java 路径。

License Server 4 装在 JDK 之后，装完把 license 文件放到固定目录，启动服务并确认端口（常见 27000 附近）在监听。SQL Server 2019 最后装，实例名建议默认，排序规则选不区分大小写，认证模式选混合模式并设 sa 密码——这个密码后面 Database Server 配置要用，同样避开特殊符号。

装 SQL Server 时容易忽略的是 TCP/IP 协议：默认实例装完后在 SQL Server 配置管理器里把 TCP/IP 启用，否则 Deployment Center 连数据库会超时。启用后重启 SQL Server 服务，用sqlcmd -S localhost -U sa能登录才算通。

三者的顺序不能反：JDK 是底座，License Server 提供许可，SQL Server 提供库。反过来装，License Server 安装程序会提示找不到 Java，SQL Server 虽然不依赖 Java，但 Deployment Center 连库测试会失败。License Server 装完后先用自带工具查一次许可状态，确认 license 文件被识别，再往下走。

3. 介质入库：Deployment Center 2406 存储库与日志排查

底座打完，进入 Deployment Center 本身。这一章的重点是把 AWC2406 的安装介质正确放进存储库，让软件存储库里出现活动的介质，否则后面创建环境时可用软件列表是空的。

3.1 介质解压：路径越短越好，D:\DeploymentCenter\repository\software

Deployment Center 默认装在D:\DeploymentCenter，存储库目录是D:\DeploymentCenter\repository\software。介质压缩包解压后直接放到这个目录下，不要套太多层，也不要放中文路径。

# 解压到存储库；-DestinationPath 控制在两级以内 Expand-Archive -Path D:\media\AWC2406_media.zip -DestinationPath D:\DeploymentCenter\repository\software\awc2406 # 看解压后顶层结构，确认有 setup 或 media 目录 Get-ChildItem D:\DeploymentCenter\repository\software\awc2406 | Select-Object Name,Mode

-DestinationPath指向存储库下的子目录，解压后路径长度尽量控制在 80 字符以内。路径太深或带中文时，Deployment Center 的 repotool 扫描会漏文件，表现为存储库里介质条目缺文件、状态不是活动。

解压完检查磁盘空间和文件数：AWC2406 介质解压后通常几个 GB，文件数上千，解压中途磁盘满会留下半截目录，后面入库时扫描报错但界面只显示添加失败，不告诉你缺哪个文件。我一般解压后先看顶层目录里有没有 media 或 setup 这类标志性文件夹，没有的话说明压缩包层级不对，重新确认解压源。

还有一个细节：不要用第三方解压工具把长路径截断。Windows 自带 Expand-Archive 对长路径支持一般，但比手工拖拽稳定；如果介质里有超长路径文件，先确认目标盘启用了长路径支持，或者换 7z 解压后核对文件数是否与压缩包内一致。

3.2 登录与添加：软件存储库里看到活动介质才算成功

浏览器打开 Deployment Center 地址，用安装时设的管理员账号登录（常见 dcadmin）。进软件存储库，点添加介质，选择刚解压的目录，提交后等扫描完成。

成功的标志是列表里出现该介质且状态为活动。如果状态是正在扫描超过十几分钟不动，基本可以判定卡住了，直接去看日志，不要反复点添加——重复提交会在存储库里留下多条半成品记录，后面清理更麻烦。

添加时选的是解压后的顶层目录，不是 zip 包本身。选错层级时 repotool 找不到 media 描述文件，日志里会报 missing media descriptor 之类的关键字。添加成功后顺手刷新一次页面，确认状态不是前端缓存出来的假活动。

3.3 添加失败翻日志：repotool\logs 下看什么

添加失败的第一现场在D:\DeploymentCenter\webserver\repotool\logs，不是浏览器控制台。

# 按时间倒序列出最近的日志文件 Get-ChildItem D:\DeploymentCenter\webserver\repotool\logs -File | Sort-Object LastWriteTime -Descending | Select-Object -First 5 Name,LastWriteTime,Length # 跟踪最新日志尾部 Get-Content (Get-ChildItem D:\DeploymentCenter\webserver\repotool\logs -File | Sort-Object LastWriteTime -Descending | Select-Object -First 1).FullName -Tail 100

第一条命令列出最近修改的 5 个日志，第二条取最新的一个看尾部 100 行。重点搜关键字：permission（目录权限）、space（磁盘空间）、descriptor（介质描述文件缺失）、timeout（扫描超时）。日志里通常能直接看到具体文件路径，比界面报错有用得多。

常见权限问题是 Deployment Center 服务账号对存储库目录没有读权限，尤其是手工解压后目录属主是当前登录用户而不是服务账号。解决方式是把存储库目录的读取权限授给服务账号，或者直接用服务账号解压。改完权限重新添加，不要在原失败记录上重试。

如果日志里出现的是扫描超时，先看介质目录下文件数是否异常多，再看磁盘 IO 是否被其他进程占满。扫描是单线程逐文件比对，机械盘上大介质会慢，但超过二十分钟基本就不是正常慢了。此时可以把介质目录复制到另一块盘上再试，排除存储本身的性能问题。

4. 环境与组件：Env_Tc 到 15 个组件的配置顺序

介质入库成功，接下来建环境、选软件、配组件。这一章是 Deployment Center 的主体操作，顺序错了会出现组件状态 100% 但部署脚本生成不了。

4.1 创建环境与概述改名

在 Deployment Center 里新建环境，默认名字可能是一串随机字符，进概述改成可读的名字，比如 Env_Tc。环境名会出现在部署脚本路径里：D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install，所以用英文、数字、下划线，不要空格和中文。

环境建好后不要急着往下点，先确认环境状态是已创建而不是初始化中。初始化没完成时，部署软件页签里可用软件列表是空的，容易误判为介质没入库。如果环境建错了名字，改概述里的名称即可，但已经生成的部署脚本路径不会跟着变，需要重新生成一次脚本。

4.2 部署软件选介质、应用程序添加

回到部署软件，在可用软件里勾选刚入库的 AWC2406 介质，点更新选定的软件。然后在已选软件里核对内容是否正确——这里如果显示的不是目标介质，后面组件配置会全部白做。

确认后点转至选项，勾选需要的选项并保存。选项里通常涉及部署模式、是否包含示例数据之类，按实际部署方案勾，不确定的保持默认。保存后页面会刷新一次，确认选项页签显示已保存而不是未保存。

再到应用程序页签，添加可用应用程序，选完点更新选定的应用程序，然后点转至组件。应用程序列表和介质版本绑定，列表为空说明介质没被正确识别，回上一章查日志。

4.3 组件配置顺序：从 Active Workspace Client Builder 到 Teamcenter Web Tier

组件页签里按顺序配，Deployment Center 对顺序有依赖，前一个没配完，后一个的某些字段是灰的。顺序如下：

每个组件点右侧展开可看详细配置。Database Server 要填 SQL Server 的主机名（和 hosts 里一致）、实例名、认证信息；Licensing Server 填 License Server 的地址和端口；Web Tier 填对外访问端口。单机部署时 Server Manager Cluster Configuration 多数保持默认。

配置过程中状态列会从 0% 往上涨，全部到 100% 才算配完。某个组件卡在 90% 通常是它依赖的上一个组件有字段没填全，往回查上一个组件的详情页，而不是在当前组件上反复点。FSC 系列三个组件依次配，FSC Keys 依赖 FSC Group，FSC Group 又依赖 FSC 的存储卷路径，顺序动了会出现字段不可编辑。

4.4 密码规则：Database Server 与 TC 不能带的那批符号

这一条是血泪经验：Deployment Center 里配置 Database Server 和 TC 的密码时，不允许出现! @ $ % = & ' " ^ : ; . _ < > ( ) { }这批特殊符号。注意里面包含下划线_，很多人密码习惯带下划线，结果保存时报校验错误，但错误提示只说密码不符合要求，不列具体字符。

TEM 里允许带特殊符号，所以同一个环境下两套密码规则不一致，配的时候容易混。我的做法是 Database Server 和 TC 用纯字母加数字的强密码（长度够即可），TEM 再用带符号的密码，两边分开记。

密码在环境创建后修改成本较高，建议在 4.1 建环境时就定好。改密码涉及重新生成部署脚本，已配置的组件状态可能被重置。把禁用字符表贴在部署记录旁边，配到密码字段时对着看一遍，比事后翻报错省时间。

5. 避坑与排查：5 个典型翻车现场

这一章按现象 → 原因 → 解决的格式记 5 个我在实际部署里反复遇到的坑，顺序按出现频率排。

5.1 介质入库一直转圈或报添加失败

现象：软件存储库点添加后，状态长时间停在正在扫描，或者直接弹添加失败，界面没有可读的错误信息。

原因：repotool 扫描介质时被目录权限、磁盘空间或路径长度卡住。最常见的是手工解压后目录属主是登录用户，Deployment Center 服务账号读不到；其次是解压路径带中文或层级过深，扫描器漏文件；磁盘满也会表现为扫描中断。

解决：先看D:\DeploymentCenter\webserver\repotool\logs最新日志，搜 permission、space、descriptor。权限问题把存储库目录读取权限授给服务账号；路径问题换短英文路径重新解压；磁盘问题清理后重新解压。不要在原失败记录上反复重试，先删掉半成品记录再添加。

5.2 组件状态卡在 90% 或 100% 但生成不了脚本

现象：组件列表里大部分到 100%，个别停在 90%，或者全部 100% 但转至部署按钮不可点。

原因：90% 通常是该组件依赖的上游字段没填全，比如 Database Server 没填实例名、Licensing Server 端口为空；全部 100% 但不能生成脚本，多半是选项页签没保存，或者应用程序没点更新选定的应用程序。

解决：从第一个非 100% 的组件往回查它的依赖组件详情页，补齐字段后点该组件的更新；全部 100% 时回选项确认已保存，再回应用程序确认已更新。生成脚本前刷新一次页面，避免前端状态缓存。

5.3 密码带下划线导致 Database Server 配置报错

现象：Database Server 配置页填完密码点保存，提示密码不符合要求，但密码长度和复杂度都够。

原因：密码里包含下划线_，属于 Deployment Center 对 Database Server 和 TC 密码禁用的那批符号。提示文案不列具体字符，只能靠对照规则排查。

解决：把密码改成纯字母加数字，去掉所有特殊符号；TEM 的密码可以保留符号，但两套要分开管理。改完密码如果环境已生成过脚本，需要重新生成部署脚本。

5.4 deploy.bat 执行时报找不到 softwareLocation

现象：解压部署包后以管理员运行 deploy.bat，报 softwareLocation 路径不存在或无法访问。

原因：-softwareLocation传的路径和实际存储库路径不一致，常见是末尾多了反斜杠、盘符大小写不一致，或者部署包解压到了没有权限的目录。

解决：路径用D:\DeploymentCenter\repository\software这种不带末尾斜杠的形式，确认该目录存在且当前管理员可读；部署包解压到短英文路径，不要在桌面或下载目录里直接跑。参数值里不要加引号，CMD 下引号会被当成路径的一部分。

5.5 主机名没改导致 License 或 Web Tier 连不上

现象：组件配置时 Licensing Server 或 Teamcenter Web Tier 保存报错，提示无法连接或解析主机；或部署脚本执行到一半失败。

原因：机器主机名和 hosts 映射、以及安装文档里写死的主机名不一致。Deployment Center 生成脚本时把主机名写进配置文件，装完再改要动多个 XML。

解决：装之前统一主机名、hosts、部署方案里的名字，三处一致；已经装了一半的，改完主机名和 hosts 后重新生成部署脚本，不要手工改已生成的配置文件，否则下次重新生成会覆盖。

6. deploy.bat 三个参数与装完后的验证清单

所有组件 100% 后点转至部署 → 生成安装脚本，成功后提示部署说明，部署包在D:\DeploymentCenter\repository\deploy_scripts\Env_Tc\install下，文件名 deploy_XXX.zip。把它解压到短英文路径，管理员打开 CMD，进解压目录执行：

deploy.bat -dcusername=dcadmin -dcpassword=dcadmin -softwareLocation=D:\DeploymentCenter\repository\software

三个参数的含义：

-dcusername和-dcpassword是 Deployment Center 自己的账号，不是 Windows 管理员账号，填错会在脚本第一步认证失败。-softwareLocation要和入库时的存储库路径完全一致，脚本会按这个路径去取介质。

执行过程中 CMD 窗口会滚动输出，不要中途关窗口。结束后看两个地方：安装目录下的日志、以及 Windows 服务列表里 Teamcenter 相关服务是否启动。验证顺序我一般这样走：先sqlcmd -S localhost -U sa确认数据库通，再浏览器访问 AWC 地址看登录页是否出来，最后用普通账号登一次看能否打开数据集。三步都过，才算装完。

从那以后我每次跑 deploy.bat 前都强制做三件事：核对主机名和 hosts、确认存储库路径不带末尾斜杠、把密码里的下划线去掉。这三步花五分钟，能省掉后面几小时的翻日志。希望帮到你。

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