企业官网建设流程全解析

简介：这份资源面向Teamcenter与Active Workspace部署工程师及运维人员，围绕使用Deployment Center安装AWC2406的完整流程展开，帮助读者在真实环境中完成从环境准备到脚本部署的全链路操作。压缩包内共1个docx文档，约4.67MB，以图文笔记形式记录关键配置界面与操作要点，便于对照执行。内容涵盖修改主机名、关闭防火墙与禁用IPv6、安装JDK17.0.3、Siemens License Server及SQL Server2019，并详细说明如何将AWC2406介质添加至Deployment Center存储库、创建与配置环境、按顺序配置Active Workspace Client、Gateway、Corporate Server、Database Server等组件，以及生成并运行deploy.bat部署脚本。文中还提示了Database Server与TC密码禁用特殊符号、TEM允许特殊符号等易错细节，并给出日志排查路径。目前已有311人学习，适合需要快速上手AWC2406部署、减少试错成本的工程师参考。

1. 从一次卡在 87% 的安装说起：Deployment Center 装 AWC2406 到底在装什么

如果你在 Siemens Teamcenter 环境里点开 Deployment Center，选好 AWC2406 的部署包，进度条走到 87% 左右突然停住，日志里反复刷 JDK 路径找不到或者 SQL Server 连接被拒——这不是玄学，是这套工具链对前置环境的校验比你想的严。Deployment Center 本质上是 Teamcenter 产品线里负责把 Active Workspace 客户端（AWC）及其依赖组件按配置模板铺到目标机器上的自动化部署器，AWC2406 是它要落地的那个版本代号。它不负责帮你装 JDK，也不负责帮你建 SQL Server 实例，它只负责“假设你已经准备好了，我来编排”。所以真正决定成败的，是你在点“Deploy”之前那半小时的环境准备。这篇笔记面向的是第一次用 Deployment Center 推 AWC2406、或者推过一次但被环境问题卡住的实施和运维人员，我会把 JDK 选型、SQL Server 准备、Deployment Center 配置、日志排查这几段拆开讲，每一步都落到你能直接抄的命令和参数上。

2. 装 AWC2406 之前，JDK 和 SQL Server 要先过哪几道关

2.1 JDK 版本不是越新越好：AWC2406 的 JDK 兼容边界

AWC2406 对 JDK 的要求有一个明确的窗口，不是“装个 JDK 就行”。常见做法是锁定 JDK 17 这一代 LTS，因为 AWC 的中间件层和 Deployment Center 自身的启动脚本都按这个基线做过验证。你如果图省事装了 JDK 21 或者更早的 JDK 8，Deployment Center 可能在启动阶段就抛UnsupportedClassVersionError，或者更隐蔽地在部署到一半时某个微服务起不来。

先确认机器上现有的 JDK：

# 查看当前默认 JDK 版本 java -version # 查看 JAVA_HOME 指向 echo $JAVA_HOME # Linux 下列出所有已安装的 JDK update-alternatives --list java

如果输出显示是 1.8 或者 21，建议单独装一个 JDK 17 并让 Deployment Center 显式指向它，而不是去动系统默认 JDK——因为同一台机器上可能还有别的 Teamcenter 组件依赖旧版本。Windows 下同理，装完 JDK 17 后不要急着改系统环境变量，先在 Deployment Center 的配置里指定绝对路径。

# Linux 示例：解压 JDK 17 到独立目录 tar -xzf jdk-17_linux-x64_bin.tar.gz -C /opt/ # 验证 /opt/jdk-17/bin/java -version

参数说明：-C /opt/指定解压目标，保持路径无空格；验证时用绝对路径调用，避免 PATH 里旧版本干扰。这一步做完先别配环境变量，等 Deployment Center 配置阶段再统一指定。

提示：JDK 环境变量配置失败最常见的原因是 PATH 里旧 JDK 排在前面，java -version看着对，但 Deployment Center 调的是另一个。用绝对路径最稳。

2.2 SQL Server 准备：实例、账号、密码策略三件事

AWC2406 的部署会往 SQL Server 里建库、建表、写初始数据，所以 Deployment Center 需要一个能建库的账号。这里踩坑最多的是三件事：实例没开 TCP/IP、账号权限不够、密码策略导致连接被拒。

先确认 SQL Server 的 TCP/IP 协议已启用，端口默认 1433。用sqlcmd测连通性：

# 测试 SQL Server 连接，-S 指定实例，-U 账号，-P 密码 sqlcmd -S 192.168.1.50,1433 -U sa -P 'YourStrongPass' -Q "SELECT @@VERSION"

如果报“已成功与服务器建立连接，但是在登录前”这类错误，通常是加密或证书问题，可以在连接串里加TrustServerCertificate=true。如果报登录失败，先查账号是不是被锁或者密码过期——SQL Server 2012 密码到期这个问题在老环境里很常见，ALTER LOGIN sa WITH PASSWORD='新密码'可以重置。

-- 确认账号能建库 SELECT name, type_desc FROM sys.server_principals WHERE name = 'sa'; -- 查看密码策略状态 SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins WHERE name = 'sa';

参数说明：is_policy_checked为 1 表示启用了密码策略，is_expiration_checked为 1 表示密码会过期。如果部署期间正好撞上过期，连接会间歇性失败，建议部署前先关掉过期检查或者换一个不过期的专用账号。

注意：不要用 sa 跑生产部署。建一个专用账号，授予dbcreator和securityadmin角色即可，够 Deployment Center 建库用。

2.3 Deployment Center 的配置入口和部署包校验

Deployment Center 启动后，第一步是导入 AWC2406 的部署包。这个包通常是一个目录或者压缩包，里面包含deploy.xml之类的描述文件。导入后工具会做一次校验，检查包完整性、JDK 路径、数据库连通性。校验不通过就不会让你进下一步。

配置 JDK 路径时，指向 JDK 17 的根目录，不是bin目录。数据库配置填实例地址、端口、账号、密码，测试连接通过后再继续。这里有一个容易忽略的点：Deployment Center 自己也是 Java 写的，它启动时用的 JDK 和它部署 AWC 时指定的 JDK 可以是两个，但建议统一，减少版本冲突。

# 启动 Deployment Center（Linux 示例） cd /opt/deployment-center ./start.sh --jdk /opt/jdk-17 --config ./config/deploy.properties

参数说明：--jdk指定 Deployment Center 自身运行用的 JDK；--config指向部署配置文件。如果启动脚本没有这些参数，就在deploy.properties里改java.home和db.url两项。

3. 用 Deployment Center 推 AWC2406 的完整操作链路

3.1 从导入部署包到预检查通过

导入部署包之后，Deployment Center 会列出这个包包含的组件清单。AWC2406 通常包含应用服务、Web 层、数据库脚本、配置模板几块。你要做的是逐项确认目标路径和端口没有冲突。预检查阶段会跑一遍环境探测，输出一份报告，里面会标红不满足的项。

# 查看预检查报告（假设输出到 logs 目录） cat /opt/deployment-center/logs/precheck-report.log | grep -i "FAIL\|ERROR"

如果报告里有 JDK 版本不匹配，回到 2.1 换路径；如果有数据库连接失败，回到 2.2 查账号和端口。预检查全绿之后再点部署，否则中途失败回滚更麻烦。

3.2 部署过程中的关键参数：端口、路径、内存

部署配置里有几个参数直接决定后面能不能跑起来。端口方面，AWC 的 Web 层默认用 8080 或 8443，如果目标机器上已经有 Tomcat 或者其他服务占了，要提前改。路径方面，安装目录不要带空格和中文，Windows 下尤其注意。内存方面，JVM 堆大小在部署配置里可以调，默认值偏保守，生产环境建议按机器内存的 50% 到 60% 设置。

# deploy.properties 关键片段 awc.web.port=8443 awc.install.dir=/opt/awc2406 awc.jvm.heap.min=2g awc.jvm.heap.max=4g db.url=jdbc:sqlserver://192.168.1.50:1433;databaseName=awc2406;encrypt=true;trustServerCertificate=true

参数说明：awc.jvm.heap.max不要超过物理内存的 70%，否则系统本身会开始换页；db.url里的trustServerCertificate=true在自签证书环境里必须加，否则连接会被拒。改完配置后重新跑一次预检查，确认没有引入新问题。

3.3 部署后验证：服务起没起、库连没连、页面开没开

部署完成不代表成功。先看服务进程：

# 检查 AWC 相关进程 ps -ef | grep awc | grep -v grep # 检查端口监听 netstat -tlnp | grep 8443

然后连数据库确认表已经建了：

-- 切换到 AWC 库 USE awc2406; -- 查看表数量 SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES;

最后用浏览器或者curl访问 Web 层：

curl -k -I https://localhost:8443/awc

返回 200 或 302 都算正常。如果返回 503，多半是应用服务没起全，去看logs目录下的应用日志。

4. 部署 AWC2406 时最容易翻车的五个地方

4.1 现象：预检查报 JDK not found，但 java -version 正常

原因：Deployment Center 用的是自己配置里的 JDK 路径，不是系统 PATH 里的。你终端里java -version显示 17，但工具配置里还指着旧的 JDK 8。

解决：打开 Deployment Center 的配置文件，找到java.home或者启动参数里的--jdk，改成 JDK 17 的绝对路径，重启工具再跑预检查。

4.2 现象：数据库连接测试通过，但部署到建表阶段失败

原因：测试连接用的账号只有连接权限，没有建库建表权限。Deployment Center 预检查阶段的连接测试比较轻量，不会真正建表。

解决：给部署账号授予dbcreator角色，或者提前手动建好空库并把 owner 设成该账号。部署完再收回权限。

4.3 现象：部署进度卡在某个百分比长时间不动

原因：通常是某个组件的启动脚本在等一个超时，比如数据库响应慢、端口被占、或者文件锁没释放。日志里会有waiting for或者timeout字样。

解决：先看日志确认卡在哪个组件，然后检查对应端口和进程。如果是数据库慢，去看 SQL Server 的当前活动会话，有没有阻塞。不要直接杀进程，等超时走完让它自己报错，这样日志更完整。

4.4 现象：部署成功但访问页面报 404 或空白

原因：Web 层上下文路径配错了，或者静态资源没解压到正确目录。AWC2406 的上下文路径默认是/awc，如果你在配置里改成了别的，访问时也要对应改。

解决：检查部署配置里的context.root参数，确认和访问 URL 一致。然后去安装目录下看webapps里有没有对应的解压目录。

4.5 现象：SQL Server 密码到期导致部署中途断开

原因：部署过程持续几十分钟，如果账号密码正好在这期间过期，后续连接全部失败。SQL Server 2012 及更早版本的默认策略容易触发。

解决：部署前用ALTER LOGIN把密码过期检查关掉，或者换一个is_expiration_checked = 0的专用账号。部署完再按安全策略恢复。

5. 把 AWC2406 部署做成可重复动作的几个技巧

部署一次成功不算本事，能重复成功才算。我一般会做三件事：把 Deployment Center 的配置文件纳入版本管理，把预检查报告和部署日志按时间戳归档，把 JDK 和 SQL Server 的准备步骤写成脚本。

配置文件版本管理不用多复杂，一个 Git 仓库就够。每次改端口、改路径、改内存参数都提交一次，下次部署直接 checkout 对应版本。日志归档用简单的mv加日期后缀：

# 归档本次部署日志 mv /opt/deployment-center/logs /opt/deployment-center/logs-$(date +%Y%m%d-%H%M) mkdir /opt/deployment-center/logs

环境准备脚本我习惯分成两段：一段查 JDK，一段查 SQL Server。查 JDK 的脚本判断版本号是否落在 17 这个区间，不在就退出并提示路径。查 SQL Server 的脚本跑一条SELECT 1，失败就打印连接串让操作人核对。

#!/bin/bash # check-env.sh：部署前环境自检 JDK_PATH="/opt/jdk-17/bin/java" if [ ! -x "$JDK_PATH" ]; then echo "JDK 17 not found at $JDK_PATH" exit 1 fi VERSION=$($JDK_PATH -version 2>&1 | head -1 | awk -F'"' '{print $2}' | cut -d. -f1) if [ "$VERSION" != "17" ]; then echo "Expected JDK 17, got $VERSION" exit 1 fi sqlcmd -S 192.168.1.50,1433 -U deploy_user -P 'Passw0rd' -Q "SELECT 1" > /dev/null 2>&1 if [ $? -ne 0 ]; then echo "SQL Server connection failed" exit 1 fi echo "Environment check passed"

这个脚本不复杂，但能挡住八成因为环境漂移导致的部署失败。每次部署前跑一遍，比事后翻日志省时间。

还有一个技巧是给 Deployment Center 的部署包做校验和记录。AWC2406 的包从不同渠道拿到，内容可能有差异。导入前先算一次 SHA256，和上一次成功的包对比，不一致就先查清楚差异在哪，别直接推。

# 计算部署包校验和 sha256sum awc2406-deploy-package.zip

最后说一个我自己的习惯：每次部署成功后，把当时的 JDK 版本、SQL Server 版本、Deployment Center 版本、关键配置参数记在一个文本文件里，和日志放一起。下次出问题，先翻上一次成功的记录，对比差异，往往比从头排查快得多。这个习惯帮我省过好几次通宵。希望帮到你。

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