Showing results for 
Search instead for 
Did you mean: 

What's New: Deployment Center 2.0

Siemens Valued Contributor Siemens Valued Contributor
Siemens Valued Contributor

With the new Deployment Center, you can manage your Teamcenter PLM environment with ease. 


Easy, flexible and cost-effective product lifecycle management (PLM) tools for deployment are critical to help you realize the value of your investment. Deployment Center provides you with a centralized web-based application that you can use to deploy Teamcenter and manage your deployments. 


Deployment Center 2.0 was released in January 2018. This release is the next step in the Deployment Center's support for installing, patching and upgrading Teamcenter software easier, faster and with lower costs.



Deployment-Center-2.jpgTeamcenter has the PLM deployment tools for you.

Instructional Deployment Center Videos for Teamcenter Customers


To learn more about how to use Deployment Center 2.0 a set of instructional videos have been created. These videos demonstrate topics such as how to install the Deployment Center, register software, set up development, test and production type environments, create custom software in the BMIDE and deploy using the Deployment Center, using software versions and build version numbers to designate release numbers, how to install and update an environment with multiple software packages simultaneously. Since each video introduces concepts about the Deployment Center and subsequent videos build on these concepts, it is suggested that the videos be viewed in order for a cohesive learning experience.


Deployment Center 2.0 demonstration videos (customer-only access)


The following is a listing of the video titles:
1. Installation of the Deployment Center
2. Registering Software
3. Creating a single box development environment
4. Creating a distributed production environment
5. Installing Foundation and Active Workspace simultaneously
6. Importing pre-existing environments
7. Adding Active Workspace to a pre-existing environment
8. Editing Environments
9. Adding a Server Pool to an environment
10. Switching the FMS Master
11. Creating and deploying a new BMIDE Template software package
12. Importing and deploying a pre-existing BMIDE Template software package
13. Deploying software on the path to production
14. Using software versions
15. Using build versions for pre-release software
16. Using a composite software project
17. Automated software package generation
18. Simultaneously installing Foundation, Active Workspace, and custom software
19. Simultaneously updating Active Workspace and custom software



Solution Partner Esteemed Contributor

The videos were a great help in understanding the scope and depth of Deployment Center. I now understand what the replacement is for compiling the tc.war file (J2EE Web Tier). I look forward to it also compiling the Login Service (ls.war) and Identity Service (id.war) for TcSSO. We will no longer need INSWEB at that point.

Community Manager

Thanks, Randy! 

Valued Contributor

Can we use DC for cloud environments yet?

Siemens Valued Contributor

The Deployment Center has a plan to support cloud type deployments. This will be something we will be looking to in the future.

Solution Partner Esteemed Contributor

Deployment Center 2.0 does not check/add the "Log on as a Service" right for the assigned user (domain user in our case). Results in deploy.bat failure because the FSC service cannot be started (logon failure). Make sure you add the user to Local Security Policies > Local Policies > User Rights Assignment > Log on as a service before running deploy.bat.

Solution Partner Esteemed Contributor

DC 2.0 does not set the system environment variable SPLM_LICENSE_SERVER so you'll need to do this manually before starting deploy.bat. Despite specifying the license server in DC, it is not honoring the value, and is defaulting to the local server. So if your license is running on a separate server the deployment fails.

Solution Partner Esteemed Contributor

DC 2.0 doesn't appear ready for prime tiime yet. The deployment created E:\tmp\transientVolume, E:\usr\Siemens\tc_data, E:\usr\Siemens\volumes and E:\usr\Siemens\Teamcenter11\security\dcEnvName_infodba.pwf despite specifying that this was being deployed to wntx64 and not linux. My advice is to wait for the next release of DC before deploying Teamcenter. Probably fine if you want to deploy Active Workspace but I didn't get that far as you can tell. Going back to using TEM.

Siemens Valued Contributor

Thanks Randy for finding these, we will be working to get these taken care of in the next releases. For the last issue with the paths, I showed Randy yesterday that there is an "Advanced" paremeters toggle that shows you a list of additoinal properties for each component you are adding to your environment. By defalut the Deployment center shows you a shortened list of parameters. You can call that the "Quick Install" option. It shows you the least amount of steps to get the products installed. This is the default option.


To use the advanced option, when you get to the "Components" task in the process map, and then click on each component (ie. Corporate Server, FCS, RAC, Pool Server, etc) there is an icon (toggle) to the right of the component name. See the screenshot below. You can see the icon with 3 veritcal lines and a upward pointing chevron.

CS toggle.png

When you click this, the Deployment center will present the list of advanced options. This includes properties for paths, as mentioned by randy, as well as many other things like service names, etc.

If you look at these advanced settings you can see the values and alter them before you generate and deploy the scripts to your environment.


Hope this helps


Gears Phenom

I did get a distributed environment installed with Deployment Center. There are a few caveats as mentioned above. Also, it is best to use DC in Chrome and not IE. That seemed to resolve the wntx64 and linux path issues and updating correctly. It isn't perfect but when it works, much easier to deploy AW than manually. 



Siemens Experimenter
My customer asks for a concept or some options in Deployment Center 2.x to clone an environment. It`s clear, that identical machines are not possible. But cloning and then changing the parameters before deployment would be a use case from my perspective.
Solution Partner Esteemed Contributor

There are two different types of cloning operations:

1. Initial Cloning - where the base software is installed first (builds TC_ROOT\install) then the DB, volumes and TC_DATA are thrown away before copying from the source environment and changing preferences.

2. Delta Cloning - where the base software install is skipped but still need to throw away and recopy the DB, delta sync volumes (mirror) and change some preferences.


These are sophisticated operations that require an in-depth knowledge to achieve. Any changes to the data model or add/remove features would need to trigger the initial cloning again. Even the feature architecture and server landscape are usually different between source/target environments. Some cloned environments require the full volumes while others only need the DBA subvolume. Asking DC to contain all this logic is asking for a lot. Not as easy as simply copying the DC output files and modify them.


Do we really want DC to handle cloning? Frankly, I'd rather see development working on a client distribution system using Bob's recent article on RAC Delta Generator (reduced rich application client deployment package).


"DC 2.0 does not set the system environment variable SPLM_LICENSE_SERVER so you'll need to do this manually before starting deploy.bat. Despite specifying the license server in DC, it is not honoring the value, and is defaulting to the local server. So if your license is running on a separate server the deployment fails." - Randy Ellsworth


This packaging and deployment tool that I wrote can set environment variables.


Request a free trial and let me know what you think.