Wednesday, August 26, 2026

Linux - WebLogic IP Address Change Procedure

 




1. Purpose

This document provides a standard procedure for changing the Linux WebLogic Server IP address when the underlying server IP address changes.

The procedure is designed to identify and update WebLogic configuration references to the old IP address while minimizing configuration impact and providing a clear rollback process.


2. Scope

This procedure applies to WebLogic domains where the server's IP address is changing.

It covers:

  • WebLogic Admin Server

  • WebLogic Managed Servers

  • Node Manager

  • startup.properties

  • WebLogic domain configuration

  • Operating system host configuration

  • Other configuration files containing the old server IP

The actual WebLogic installation and domain paths may vary by environment.


3. Prerequisites

Before starting the IP address change:

  1. Confirm the current/old IP address.

  2. Confirm the new IP address.

  3. Confirm the new IP is assigned to the server.

  4. Verify network connectivity using the new IP.

  5. Obtain appropriate OS and WebLogic administrative access.

  6. Schedule an appropriate maintenance window.

  7. Confirm all WebLogic services that will be impacted.

  8. Take a backup of the WebLogic domain configuration.


4. Verify Current Server Configuration

Check the current IP address:

hostname -I

or:

ip addr

Verify hostname resolution:

hostname
hostname -f

Check /etc/hosts if applicable:

cat /etc/hosts

Verify connectivity to the new IP or required network endpoints before proceeding.


5. Stop WebLogic Services

Stop the WebLogic Admin Server, Managed Servers, and Node Manager as required by the environment's standard shutdown procedure.

Verify that WebLogic processes have stopped:

ps -ef | grep -i weblogic | grep -v grep

Do not proceed with configuration changes while active WebLogic processes are using the configuration being modified.


6. Backup WebLogic Configuration

Identify the WebLogic domain directory.

Example:

export DOMAIN_HOME=/path/to/weblogic/domain

Create a backup before making any changes:

tar -czvf ${DOMAIN_HOME}_backup_$(date +%Y%m%d_%H%M%S).tar.gz "$DOMAIN_HOME"

Verify the backup:

ls -lh ${DOMAIN_HOME}_backup_*.tar.gz

Keep the backup until the IP change has been successfully validated.


7. Identify References to the Old IP

Search the WebLogic domain for references to the old IP address:

grep -RIn "OLD_IP_ADDRESS" "$DOMAIN_HOME" 2>/dev/null

Replace OLD_IP_ADDRESS with the actual old IP.

Also search specifically for startup.properties:

find "$DOMAIN_HOME/servers" \
-type f \
-name "startup.properties" \
-exec grep -Hn "OLD_IP_ADDRESS" {} \;

This identifies only the startup.properties files that contain the old IP.


8. Update startup.properties

startup.properties files may contain server-specific configuration, including IP addresses.

Before modifying these files:

  • Confirm the old IP belongs to the server being changed.

  • Do not modify files that do not contain the old IP.

  • Create a backup of each file being modified.

A generic replacement command is:

find "$DOMAIN_HOME/servers" \
-type f \
-name "startup.properties" \
-exec grep -l "OLD_IP_ADDRESS" {} \; \
-exec cp {} {}.bak \; \
-exec sed -i 's/OLD_IP_ADDRESS/NEW_IP_ADDRESS/g' {} \;

Where:

OLD_IP_ADDRESS = Current server IP
NEW_IP_ADDRESS = New server IP

Important

The command above modifies a startup.properties file only when the old IP is found.

Files that do not contain the old IP are not modified.


9. Review Other WebLogic Configuration

The IP address may be referenced in locations other than startup.properties.

Search the entire WebLogic domain:

grep -RIn "OLD_IP_ADDRESS" "$DOMAIN_HOME" 2>/dev/null

Review any references found in areas such as:

  • config.xml

  • startup.properties

  • Node Manager configuration

  • WebLogic startup scripts

  • Admin Server configuration

  • Managed Server configuration

  • Machine configuration

  • JDBC configuration

  • JMS configuration

  • SSL configuration

  • Listen Address configuration

  • Application configuration

  • Custom scripts

Do not automatically replace every occurrence. Review each reference to determine whether the IP should actually change.


10. Check Node Manager

Review the Node Manager configuration if Node Manager uses the server IP.

Typical location:

$DOMAIN_HOME/nodemanager/nodemanager.properties

Search for the old IP:

grep -n "OLD_IP_ADDRESS" \
"$DOMAIN_HOME/nodemanager/nodemanager.properties"

If the old IP is configured and should be replaced, update it with the new IP.


11. Check Operating System Configuration

Review /etc/hosts:

grep -n "OLD_IP_ADDRESS" /etc/hosts

If the old IP is configured for the WebLogic server, update it as required.

Verify hostname resolution:

getent hosts $(hostname)

12. Check External Dependencies

The WebLogic server IP may also be referenced outside the WebLogic domain.

Review the following where applicable:

  • DNS

  • Load Balancers

  • Reverse Proxies

  • Firewalls

  • Network ACLs

  • Monitoring systems

  • Backup systems

  • Security tools

  • Application integrations

  • Database connectivity

  • SSO integrations

  • API integrations

  • External systems

  • Infrastructure automation

  • Server Manager configuration

Coordinate with the appropriate infrastructure or application teams when these components are managed outside the WebLogic team.


13. Verify Configuration Changes

After making the changes, search for the old IP again:

grep -RIn "OLD_IP_ADDRESS" "$DOMAIN_HOME" 2>/dev/null

Review any remaining references.

Then verify the new IP:

grep -RIn "NEW_IP_ADDRESS" "$DOMAIN_HOME" 2>/dev/null

Confirm that the new IP appears only where expected.


14. Start WebLogic

Start the WebLogic environment using the standard startup procedure.

Verify WebLogic processes:

ps -ef | grep -i weblogic | grep -v grep

Confirm:

  • Admin Server is running.

  • Managed Servers are running.

  • Node Manager is running.

  • Applications are accessible.


15. Validate WebLogic

Review WebLogic logs after startup.

For example:

find "$DOMAIN_HOME/servers" -type f -name "*.log" -mmin -30

Search for common startup and connectivity errors:

grep -RInE "ERROR|Exception|Connection refused|UnknownHost|BEA-" \
"$DOMAIN_HOME/servers" 2>/dev/null

Validate application connectivity and any integrations dependent on the WebLogic server.


16. Post-Change Validation

Complete the following checks:

  • New server IP is configured correctly.

  • Network connectivity verified.

  • WebLogic domain backup completed.

  • Old IP references identified.

  • Required startup.properties files updated.

  • Only files containing the old IP were modified.

  • Node Manager configuration reviewed.

  • /etc/hosts reviewed.

  • WebLogic configuration reviewed.

  • DNS/load balancer configuration validated.

  • Admin Server started successfully.

  • Managed Servers started successfully.

  • Node Manager validated.

  • Application connectivity validated.

  • WebLogic logs reviewed.

  • External integrations validated.


17. Rollback Procedure

If WebLogic or an application does not function correctly after the IP change:

  1. Stop the affected WebLogic services.

  2. Identify the configuration changes made.

  3. Restore the affected configuration files from their .bak files or the domain backup.

  4. Restore the previous server/network configuration if required.

  5. Restart WebLogic.

  6. Validate the environment.

For individual startup.properties files:

cp startup.properties.bak startup.properties

For a complete domain rollback, restore the WebLogic domain from the backup created before the change.


18. Change Management Summary

The recommended sequence is:

Validate New IP → Stop WebLogic → Backup Domain → Search Old IP → Update Required Configuration → Validate Configuration → Start WebLogic → Validate WebLogic → Validate Applications → Close Change

Key Principle

Do not perform a blanket IP replacement across the WebLogic domain. Identify each reference to the old IP and update only the configuration entries that are required for the server IP change.

Thursday, June 4, 2026

JD Edwards Printer Setup and Validation on Linux (CUPS)

 

Overview

This document provides step-by-step instructions for defining, validating, and troubleshooting printers in a JD Edwards (JDE) environment using Linux CUPS (Common UNIX Printing System). It includes printer configuration, Linux validation, JDE setup, printer queue management, and end-user validation.


1. Define Printer in Linux CUPS

Printer definitions in Linux are managed through the CUPS configuration.

Navigate to CUPS Configuration Directory

cd /etc/cups

Open Printer Configuration File

vi printers.conf

Verify Printer Definition

Ensure the printer is properly configured and available in the printers.conf file.

Example printer names:

  • PRT001
  • PRT002
  • APCHECK

Note: The printer name defined in Linux/CUPS should match the printer configured in JD Edwards.


2. Test Print from Linux

After defining the printer, validate functionality directly from the Linux server.

Test Print Commands

echo "Test Print Successful" | lpr -P PRT001

PRT001 is a printer defined in JD Edwards.

echo "Test Print Successful" | lpr -P PRT002

PRT002 is a printer defined in JD Edwards.

lpr -P APCHECK testprint

APCHECK is a printer defined in JD Edwards.

Expected Result

The test print should be successfully submitted to the printer queue and printed.


3. Review Printer Logs

If printing issues occur, review the CUPS logs to validate print job activity.

Access Log Validation

tail /var/log/cups/access_log

Example Successful Log Entries

"POST /printers/APCHECK HTTP/1.1" 200 306 Create-Job successful-ok
"POST /printers/APCHECK HTTP/1.1" 200 279 Send-Document successful-ok

Error Log Validation

tail /var/log/cups/error_log

Purpose of Logs

  • access_log → Validates if print requests are reaching the printer queue.
  • error_log → Helps identify printer, permission, or communication failures.

4. Define Printer in JD Edwards

Navigate to the printer setup application in JD Edwards.

Application

P98616 – Printer Revisions

Steps

  1. Open P98616.
  2. Add or validate the printer definition.
  3. Ensure the printer name matches the Linux/CUPS printer definition.
  4. Verify printer mapping and output queue configuration.

5. Pause Printer on Linux/Unix

To validate queued print jobs or temporarily stop printing, disable the printer queue.

Pause Printer

cupsenable JAX002
cupdisable JAX002

Purpose

This allows validation of whether print jobs are entering the Linux print queue without immediately printing.


6. Validate Printer from JD Edwards (Print Immediate)

Submit a test report from JD Edwards.

Run Report

R0006P | XJDE0005

On Printer Selection - Chnage Printer to PRT001
On Document Setup - Print Immediate






Submit Job

Expected Result

The report should submit successfully to the printer queue.


7. Verify Printer Queue on Linux

Validate that the print job is waiting in the queue while the printer is paused.

Check Queue Status

lpstat -p

Check Pending Jobs

lpstat -o

Expected Result

The submitted print job should appear in a waiting state.


8. Release Printer Queue

After validating the queued job, enable the printer to allow processing.

Release Printer

cupsenable JAX002

Expected Result

The queued print job should begin processing and print successfully.


9. Validate Print Output

Re-run the test report if necessary:

R0006P | XJDE0005

Validation Checklist

  • Print job submitted successfully from JDE
  • Job visible in Linux print queue
  • No CUPS errors observed
  • Physical print output generated successfully

10. User Validation

Request end-user confirmation for the printed document.

User Validation Points

  • Print formatting is correct
  • Printer selection is correct
  • No missing pages or formatting issues
  • Successful delivery to the expected printer

Friday, May 1, 2026

PowerShell Script to Check if Visual Studio 2022 Is Installed on Remote Servers

Managing multiple Windows servers can be challenging, especially when you need to verify whether specific software is installed across your environment. One common request in enterprise IT environments is checking whether Visual Studio 2022 is installed on remote servers.

Instead of manually logging into each machine, you can automate the process using PowerShell Remoting.

In this blog, I’ll show you a PowerShell script that connects to remote servers, checks for Visual Studio 2022, displays results on screen, and exports the report to CSV.


Why Use This Script?

This script helps system administrators and IT teams:

  • Audit software installations across multiple servers
  • Verify developer tools are installed where needed
  • Save time by avoiding manual checks
  • Generate reports for compliance or inventory purposes

Requirements

Before running:

Enable PowerShell Remoting

Run on remote servers:

Enable-PSRemoting -Force

Firewall Access

Ensure WinRM ports are open.

Permissions

Run the script using an account with admin rights on target servers.

PowerShell Script

# List of remote servers
$Servers = @("Server01","Server02","Server03")
# Output file $OutputFile = "C:\Temp\VS2022_Check_Report.csv" # Create results array $Results = @() foreach ($Server in $Servers) { Write-Host "Checking $Server ..." -ForegroundColor Cyan try { $Result = Invoke-Command -ComputerName $Server -ScriptBlock { # Search registry for Visual Studio 2022 $paths = @( "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*", "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" ) $vs = Get-ItemProperty $paths -ErrorAction SilentlyContinue | Where-Object { $_.DisplayName -match "Visual Studio" -and $_.DisplayName -match "2022" } | Select-Object -First 1 DisplayName, DisplayVersion if ($vs) { [PSCustomObject]@{ Installed = "Yes" Product = $vs.DisplayName Version = $vs.DisplayVersion } } else { [PSCustomObject]@{ Installed = "No" Product = "" Version = "" } } } $Results += [PSCustomObject]@{ Server = $Server Installed = $Result.Installed Product = $Result.Product Version = $Result.Version } } catch { $Results += [PSCustomObject]@{ Server = $Server Installed = "Connection Failed" Product = "" Version = "" } } } # Show output on screen $Results | Format-Table -AutoSize # Export CSV $Results | Export-Csv $OutputFile -NoTypeInformation Write-Host "`nReport saved to $OutputFile" -ForegroundColor Green

How This Script Works

1. Server List

Add all your remote servers inside the $Servers array.

$Servers = @("Server01","Server02","Server03")

2. Remote Connection

The script uses:

Invoke-Command

This runs commands remotely on each server using PowerShell Remoting.

3. Registry Search

It checks Windows uninstall registry paths:

  • 64-bit software path
  • 32-bit software path

Then searches for:

  • Visual Studio
  • 2022

4. Output Example

ServerInstalledProductVersion
Server01        YesVisual Studio Professional 202217.8
Server02        No
Server03       Connection Failed

CSV Report Output

The script automatically creates:

C:\Temp\VS2022_Check_Report.csv

Useful for:

  • Audits
  • Asset management
  • Compliance reporting


Tuesday, January 20, 2026

JDE Sender Email Logic Explained: How JD Edwards Determines “From” Email Address


In JD Edwards EnterpriseOne (JDE), outbound emails are generated from different system components such as workflows, UBE reports, table triggers, business functions, and shortcuts. One common challenge for administrators and developers is understanding:

Which email address is used as the sender (“From”) based on functionality?

This blog breaks down the sender email hierarchy clearly so you can design, troubleshoot, and govern email behavior in JDE environments.

1. Workflow Email Sender

For JDE Workflow-generated emails, the system uses a fixed system email address.

Sender:

PSFT_SYSTEM@domainname.com

2. UBE (Universal Batch Engine) Email Sender

UBE email behavior is tied directly to the user running the report.

Sender:

User’s Who’s Who Email Address


3. Shortcut Email Sender

Shortcuts (menu-driven or fast path actions that trigger emails) follow a hierarchical fallback model.

Sender Hierarchy:

  1. Primary: User’s Who’s Who Email Address
  2. Fallback: PSFT_SYSTEM@domainname.com (if user email is not configured)

4. Table Trigger Email Sender

Table triggers fire automatically when database events occur (insert/update/delete).

Sender Hierarchy:

  1. Primary: User’s Who’s Who Email Address
  2. Fallback: PSFT_SYSTEM@domainname.com


5. Business Function Email Sender

Business Functions (BSFN) are custom or standard backend logic components in JDE.

Sender Hierarchy:

  1. Primary: User’s Who’s Who Email Address
  2. Fallback: PSFT_SYSTEM@domainname.com


SMTP Validation for JD Edwards (JDE) Using PowerShell


Email delivery is a critical part of JD Edwards EnterpriseOne (JDE) for workflows, UBE reports, notifications, and system alerts. When emails fail, the root cause is often SMTP configuration or network connectivity.

This blog provides a step-by-step SMTP validation approach using PowerShell and JDE configuration checks to ensure end-to-end email delivery is working correctly.

1. Verify SMTP Server Connectivity

Before checking JDE or email configuration, ensure the SMTP server is reachable from the Enterprise Server.

PowerShell Command:

Test-NetConnection smtp.server.com -Port 25

What This Checks:

  • Network connectivity to SMTP server
  • Port availability (typically 25, 587, or 465)
  • Basic firewall or routing issues

Expected Output:

  • TcpTestSucceeded : True → SMTP reachable
  • False → Network/firewall issue

2. JDE INI SMTP Configuration

JDE uses the Enterprise Server INI file to define email routing rules and system email identities.

Sample Configuration:

Rule1=90|OPT|MAILSERVER=smtp.server.com 

Rule2=100|DEFAULT|OWMON=OWMON@domain.com

Rule3=110|DEFAULT|PSFT_SYSTEM=PSFT_System@domain.com

Rule4=120|DEFAULT|JDE_SYSTEM=JDE_System@domain.com

Rule5=DEFAULT|WORKFLOW_SYSTEM=Workflow@domain.com

SMTPPort=25

Explanation:

SettingPurpose
MAILSERVERDefines SMTP host
SMTPPortSMTP port (usually 25)
OWMONSystem monitoring email
PSFT_SYSTEMDefault PeopleSoft/JDE system sender
JDE_SYSTEMJDE system-generated emails
WORKFLOW_SYSTEMWorkflow email sender

Key Insight:

These rules determine which sender email is used depending on functionality inside JDE.

3. PowerShell SMTP Email Test (Enterprise Server)

Once network and configuration are validated, test actual email delivery using PowerShell.

Script:

Send-MailMessage `
-From "JDE_System@domain.com" `
-To "xxxxxx@domain.com" `
-Subject "SMTP Test" `
-Body "This is a test email from JDE Enterprise Server" `
-SmtpServer smtp.server.com `
-Port 25

What This Validates:

  • SMTP authentication (if required)
  • Email relay permissions
  • Network path from Enterprise Server
  • Basic email delivery capability

If This Fails:

Check:

  • SMTP relay permissions
  • Firewall rules
  • Authentication requirements (anonymous relay vs credentials)
  • TLS requirements (port 587 instead of 25)

4. JDE Functional Email Validation

After SMTP validation, confirm JDE configuration and functional email behavior.

Step 1: Enable Email on Job Completion

Ensure the following INI setting is enabled:

  • “Send Email on Job Completion” option in UBE configuration

Step 2: Configure Who’s Who Email

In JDE:

  • Go to Address Book → Who’s Who
  • Add valid email address for user

Step 3: Assign Address Number

  • Ensure User Profile is linked to correct Address Number
  • Without this mapping, email routing may fail or fallback to system sender

Step 4: Run Test UBE

  • Execute a sample batch job (UBE)
  • Enable email notification on completion
  • Verify email delivery

6. Common Issues and Fixes

❌ Email Not Sending

  • SMTP server unreachable
    ✔ Fix: Check firewall / port 25 access

❌ Email Sent but From Address Wrong

  • Missing Who’s Who email
    ✔ Fix: Update Address Book email

❌ Emails Failing Only from JDE

  • INI misconfiguration
    ✔ Fix: Validate MAILSERVER and RULES

❌ UBE Email Not Triggering

  • Notification not enabled
    ✔ Fix: Enable “Send Email on Completion”

7. Best Practices

✔ Always use system sender fallback

Example:

✔ Standardize SMTP relay

  • Avoid multiple SMTP servers unless required

✔ Maintain Who’s Who emails

  • Critical for correct sender identity

✔ Monitor failed email logs

  • JDE logs + SMTP logs together provide full visibility

Final Thoughts

SMTP validation in JD Edwards is not just a network test—it is a three-layer validation process:

  1. Network layer (SMTP reachability)
  2. System layer (INI configuration)
  3. Application layer (JDE functional behavior)

Using PowerShell along with JDE configuration checks ensures end-to-end email reliability across workflows, UBEs, and system processes