Workflow approval task notifications not sent via SMTP after cloud migration

PLM Teamcenter
, , , , , , , ,
1

We recently migrated our Teamcenter 13.1 workflow management module to a cloud environment and ran into a critical issue with SMTP notifications. Workflow approval tasks are created successfully, but email notifications are not being delivered to assignees.

Our on-premise setup used basic SMTP authentication without issues. In the cloud deployment, we’re seeing connection timeouts in the logs:


SMTPTransport.connect() failed
javax.mail.MessagingException: Connection timed out
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:2189)

We’ve verified the SMTP server credentials are correct and the workflow notification configuration appears unchanged from our on-prem setup. The cloud firewall rules allow outbound traffic on port 587, but I’m wondering if there’s something specific about SMTP authentication methods or additional cloud network configurations we’re missing. Has anyone successfully configured workflow notifications after a cloud migration?

system 2

The timeout you’re seeing is definitely network-related rather than authentication. Here’s what worked for our cloud migration:

SMTP Authentication Method: Update your Teamcenter mail properties to use explicit STARTTLS. In your wt.properties or mail configuration:


mail.smtp.auth=true
mail.smtp.starttls.enable=true
mail.smtp.starttls.required=true
mail.smtp.ssl.protocols=TLSv1.2

Cloud Firewall Rules: This is the critical part. You need both:

  1. Security group egress rule allowing TCP 587 to your SMTP server’s IP range
  2. Network ACL outbound rule on the subnet (often forgotten)
  3. Verify no service control policies blocking SMTP at the organization level

Test connectivity first: telnet smtp.yourprovider.com 587 from the Teamcenter server. If that times out, it’s definitely firewall-related.

Workflow Notification Config: Verify these Teamcenter-specific settings:

  • Notification Agent is running (NotificationAgent service status)
  • Queue Manager configuration includes mail transport
  • Workflow process template has notification steps properly configured
  • Check $TC_ROOT/logs/notification_agent.log for detailed errors

For cloud deployments, I strongly recommend using your cloud provider’s SMTP relay service (AWS SES, Azure Communication Services, etc.) instead of external SMTP servers. They’re pre-configured with proper firewall rules and authentication mechanisms. You’ll need to update your SMTP endpoint to the relay service and use IAM-based authentication or API keys instead of username/password.

If using external SMTP, ensure your mail server allows connections from your cloud IP range - many providers block cloud datacenter IPs due to spam concerns. You might need to whitelist your elastic IPs with your SMTP provider.

After making these changes, restart the Notification Agent service and test with a simple workflow approval task. Monitor both Teamcenter notification logs and your SMTP server logs to confirm successful delivery.

This draft is based on general Teamcenter knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Check if your cloud provider requires explicit egress rules for SMTP traffic. Port 587 being open isn’t always enough - some cloud platforms block SMTP by default to prevent spam. You might need to request SMTP relay service or use an authenticated relay endpoint.

4

I’ve seen this exact issue before. The problem is usually related to TLS/STARTTLS requirements in cloud environments. Your on-premise setup likely used unencrypted SMTP, but cloud providers typically enforce encrypted connections. Check your mail.smtp.starttls.enable and mail.smtp.ssl.enable properties in your Teamcenter configuration. You’ll probably need to enable STARTTLS and ensure your SMTP server supports it. Also verify that the authentication mechanism matches what your SMTP provider expects - some require PLAIN, others need LOGIN or CRAM-MD5.

5

Beyond the SMTP configuration itself, have you checked your cloud security groups and network ACLs? Even with port 587 open, you might have restrictive outbound rules at the subnet level. Also, some cloud environments use NAT gateways that need specific routing configurations for SMTP traffic. I’d recommend testing SMTP connectivity directly from your Teamcenter server using telnet or a simple mail test utility to isolate whether it’s a network issue or a configuration problem.

7

One thing that often gets overlooked in cloud migrations is DNS resolution for SMTP servers. If your on-premise setup used internal DNS names for the mail server, those might not resolve correctly in the cloud. Verify that your SMTP hostname resolves to the correct IP address from within your cloud network. You might need to update DNS configurations or use fully qualified domain names. Also check if your cloud provider has any specific SMTP relay services that are recommended for their infrastructure - using those can simplify authentication and firewall configurations significantly.

9

I’d also verify your workflow notification templates haven’t been corrupted during migration. Sometimes the notification configuration gets partially migrated and you end up with missing sender addresses or malformed headers that cause silent failures. Check the Workflow Administrator for any error messages in the notification logs, not just the SMTP transport logs.