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

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

Server	Installed	Product	Version
Server01	Yes	Visual Studio Professional 2022	17.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

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.

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:

Setting	Purpose
MAILSERVER	Defines SMTP host
SMTPPort	SMTP port (usually 25)
OWMON	System monitoring email
PSFT_SYSTEM	Default PeopleSoft/JDE system sender
JDE_SYSTEM	JDE system-generated emails
WORKFLOW_SYSTEM	Workflow 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:

• PSFT_SYSTEM@domain.com as default

✔ 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. 

JDE Security History (F9312) – Tracking User Activity, Logins, Additions, and Deletions

In Oracle JD Edwards EnterpriseOne, security auditing is a critical capability for tracking user behavior, compliance, and system integrity. One of the most important tables used for this purpose is F9312 – Security History Table, which captures key security events such as logins, user creation, and deletions.

This blog explains how to use F9312 effectively with practical SQL queries for common audit requirements.

What is F9312?

The F9312 (Security History File) stores historical security event logs generated by JD Edwards EnterpriseOne Security Server.

It helps track:

• Failed login attempts
• User creation events
• User deletion events
• Other security-related activities

Each record includes:

• User ID
• Event Type (SHEVTYP)
• Event Status (SHEVSTAT)
• Date (SHUPMJ – Julian date format)
• Time and additional audit details

1. Failed Login Attempts for a Specific User

To identify failed login attempts for a user:

SELECT *
FROM SY920.F9312
WHERE SHUSER = 'xxxxx'
  AND SHEVTYP = '01'
  AND SHEVSTAT = '02';

Explanation:

• SHUSER → User ID
• SHEVTYP = '01' → Login Event
• SHEVSTAT = '02' → Failed Login Status

👉 This query helps detect brute-force attempts or incorrect password usage patterns.

2. User Creation Events (From a Given Date)

To track when users were added:

SELECT *
FROM SY920.F9312
WHERE SHEVTYP = '05'
  AND SHUPMJ >= 125001;

Explanation:

• SHEVTYP = '05' → User Creation Event
• SHUPMJ >= 125001 → Records from 01-Jan-2025 onwards (Julian format)

👉 Useful for onboarding audits and compliance checks.

3. User Deletion Events (From a Given Date)

To track deleted users:

SELECT *
FROM SY920.F9312
WHERE SHEVTYP = '06'
  AND SHUPMJ >= 125001;

Explanation:

• SHEVTYP = '06' → User Deletion Event
• SHUPMJ >= 125001 → From 01-Jan-2025 onwards

👉 Helps ensure no unauthorized user removals occurred.

4. Common SHEVTYP (Event Types)

Below are some commonly used event type codes in F9312:

Here is a List of all Event Tyoe (SHEVTYP)

Why F9312 is Important

Using F9312 effectively helps organizations:

• Strengthen security monitoring
• Detect suspicious login behavior
• Maintain compliance (SOX, audit requirements)
• Track administrative changes in real time
• Improve governance in ERP systems

Best Practices

• Regularly archive F9312 data to avoid performance issues
• Build dashboards for failed login trends
• Alert on repeated failed login attempts
• Combine with user profile tables for deeper analysis
• Restrict access to security audit tables
• 
  

Final Thoughts

The F9312 Security History table in Oracle JD Edwards EnterpriseOne is a powerful but often underutilized tool. With the right queries and monitoring strategy, it can significantly improve your enterprise security posture and audit readiness.

SQL Server: Identify Data Files with Less Than 10% Free Space

 

In database administration, monitoring storage utilization is critical to avoid performance degradation, blocking issues, and unexpected outages. One of the most important checks for a DBA is identifying data files that are running low on free space.

In this blog, we’ll look at a practical approach to identify database files in Microsoft SQL Server that have less than 10% free space using a dynamic query across all databases.

Why Monitoring File Space Matters

When data files run out of space, it can lead to:

• Transaction failures
• Slow query performance
• Blocking and deadlocks
• Application downtime
• Emergency auto-growth events (which are expensive)

Proactive monitoring helps DBAs:

• Plan storage expansion
• Avoid emergency outages
• Optimize database performance

Solution Overview

The following script:

• Scans all databases
• Collects data file size and free space
• Stores results in a temporary table
• Filters files with less than 10% free space

SQL Query to Identify Low-Space Data Files

CREATE TABLE #FileSize

(

    dbName NVARCHAR(128), 

    FileName NVARCHAR(128), 

    type_desc NVARCHAR(128),

    CurrentSizeMB DECIMAL(10,2), 

    FreeSpaceMB DECIMAL(10,2),

    FreeSpacePercentage DECIMAL(10,2)

);

INSERT INTO #FileSize

(dbName, FileName, type_desc, CurrentSizeMB, FreeSpaceMB, FreeSpacePercentage)

EXEC sp_msforeachdb 

'

USE [?];

SELECT 

    DB_NAME() AS DbName,

    name AS FileName,

    type_desc,

    CAST((size * 8.0 / 1024) AS DECIMAL(10, 2)) AS CurrentSizeMB,

    CAST(((size - FILEPROPERTY(name, ''SpaceUsed'')) * 8.0 / 1024) AS DECIMAL(10, 2)) AS FreeSpaceMB,

    CAST((((size - FILEPROPERTY(name, ''SpaceUsed'')) * 100.0) / size) AS DECIMAL(10, 2)) AS FreeSpacePercentage

FROM sys.database_files

WHERE type IN (0,1);

';

SELECT * 

FROM #FileSize

WHERE dbName NOT IN ('distribution', 'master', 'model', 'msdb')

AND FreeSpacePercentage < 10;

DROP TABLE #FileSize;

How This Query Works

1. Temporary Table Creation

A staging table #FileSize is created to store results from all databases.

2. Iterating Through All Databases

We use:

sp_msforeachdb

This stored procedure loops through every database in the instance and executes the query.

3. Collecting File Metrics

From:

sys.database_files

We extract:

• File name
• File type (data/log)
• Total size
• Used space
• Free space percentage

4. Filtering Critical Files

We exclude system databases:

• master
• model
• msdb
• distribution

Then we filter:

FreeSpacePercentage < 10

This highlights files that are running critically low on space.

Output Example

dbName	FileName	type_desc	CurrentSizeMB	FreeSpaceMB	FreeSpacePercentage
SalesDB	Sales_Data	ROWS	20480	1200	5.8
HRDB	HR_Data	ROWS	10240	800	7.9

Best Practices

1. Set Alerts

Integrate this query into SQL Agent jobs for proactive alerting.

2. Avoid Frequent Auto-Growth

Instead of relying on auto-growth, plan capacity ahead of time.

3. Separate Data and Log Monitoring

Data files and log files behave differently—monitor both independently.

4. Use Performance Dashboards

Visualize file growth trends using tools like:

• Power BI
• Grafana
• SSRS

Enhancements You Can Add

If you want to extend this script further:

• Add disk-level free space checks
• Include auto-growth settings
• Identify top growing databases
• Export results to email alerts

Final Thoughts

In Microsoft SQL Server environments, storage issues are one of the most common causes of production incidents. This simple query helps DBAs proactively identify databases running low on space and take corrective action before users are impacted.

Understanding ESU and ASU Process in JD Edwards – How Object Installation Decisions Are Made

In Oracle JD Edwards EnterpriseOne, Software Updates play a critical role in keeping environments stable, secure, and up to date. Two key components of this update mechanism are:

• ESU (Electronic Software Update)
• ASU (Application Software Update)

A common question for administrators and developers is:

How does JDE decide whether an object should be added, replaced, or skipped during an ESU/ASU installation?

This blog explains the internal logic behind that decision and how the system uses key tables such as F96400 and F9672.

What are ESU and ASU?

ESU (Electronic Software Update)

ESU delivers fixes or enhancements for specific objects in JD Edwards applications.

ASU (Application Software Update)

ASU is a broader update mechanism that may include multiple ESUs and object-level changes.

Both follow similar object comparison logic during installation.

Key Tables Used in Decision Making

JD Edwards uses two important tables during the ESU/ASU process:

1. F96400 (SGESUDM)

• Stores ESU object metadata
• Contains update date for the incoming ESU object
• Field of interest: SGESUDM

2. F9672 (SUSUDATE)

• Stores software update history
• Tracks previously applied objects in the environment
• Field of interest: SUSUDATE

Core Decision Logic

The system determines whether an object should be:

• Added
• Replaced
• Merged (legacy only, removed in 64-bit systems)

Decision Rule:

If SGESUDM > SUSUDATE → Object is REPLACED

In simple terms:

• If the incoming ESU object is newer → Replace existing object
• If the dates are equal or older → No replacement or conditional handling

Important Notes

1. F9861 is NOT used

The ESU installation process does not check F9861 to decide object installation.

2. MERGE Option Removed in 64-bit

In modern JD Edwards environments:

• Only ADD and REPLACE are supported
• MERGE functionality has been removed

SQL to Identify All Objects That Will Be Replaced

Before applying an ESU (example: UN9), you can identify impacted objects using:

SELECT 
    T1.SGOBNM,
    T1.SGESUP,
    T1.SGESUDM,
    T2.SUOBNM,
    T2.SUPKGNAME,
    T2.SUSUDATE,
    T2.SUPATHCD
FROM JDESY920.F96400 T1
JOIN JDESY920.F9672 T2
    ON T1.SGOBNM = T2.SUOBNM
WHERE T1.SGESUP = 'UN9'
  AND T2.SUPATHCD = 'PD920'
  AND T1.SGESUDM > (
        SELECT MAX(T3.SUSUDATE)
        FROM JDESY920.F9672 T3
        WHERE T3.SUOBNM = T1.SGOBNM
          AND T3.SUPATHCD = 'PD920'
  );

What this shows:

• Objects that will be REPLACED
• New ESU objects not yet applied
• Impact scope before deployment

Object-Level Comparison Example

Example 1 – Replace Scenario

SELECT SUOBNM, SUPKGNAME, SUSUDATE, SUPATHCD
FROM JDESY920.F9672
WHERE SUPATHCD = 'DV920'
  AND SUOBNM = 'B9600186';

SELECT SGOBNM, SGESUP, SGESUDM
FROM JDESY920.F96400
WHERE SGESUP = 'UN9'
  AND SGOBNM = 'B9600186';

Interpretation:

If:

SGESUDM > SUSUDATE

👉 Object will be REPLACED

Why This Logic Matters

Understanding ESU decision logic helps:

• Avoid unexpected object overwrites
• Predict deployment impact
• Reduce downtime during ESU application
• Improve change management planning
• Support audit and compliance requirements

Common Use Case Before Applying ESU (UN9 Example)

Before installing ESU package like UN9, administrators should:

1. Extract ESU package
2. Install in Planner Environment
3. Run comparison SQL
4. Identify:
   • Objects to be replaced
   • New objects to be added
   • No-change objects

Reference Oracle Support Documents

• E1: ESU Install Process Under the Covers (Doc ID: 2388199.2)
• How to Force Merge or Re-Merge Objects (Doc ID: 790705.1)
• Why Objects Are Merged vs Replaced (Doc ID: 660444.1)
• Net Change Functionality of Software Updates (Doc ID: 651812.1)

Final Thoughts

The ESU/ASU process in Oracle JD Edwards EnterpriseOne is driven by a simple but powerful rule set based on object metadata comparison.

At the core:

SGESUDM (incoming ESU) vs SUSUDATE (existing system)

Understanding this logic allows technical teams to:

• Predict update impact accurately
• Avoid production surprises
• Improve deployment confidence

Powershell Command over PrintQueue

In JD Edwards EnterpriseOne (JDE) environments, file management in directories like PrintQueue, media objects, and upload folders becomes critical for performance, cleanup, and troubleshooting.

Over time, these folders grow significantly, especially in production environments. PowerShell provides a fast and reliable way to analyze, filter, copy, and count JDE-related files.

This blog covers practical PowerShell commands used in real JDE environments for PrintQueue analysis and file operations.

1. Finding JDE PrintQueue Information

The PrintQueue directory in JDE stores batch print outputs, reports, and spool files. Over time, it accumulates large volumes of data.

Typical Path:

C:\JDEdwardsPPack\E920\PrintQueue

You can inspect files using:

Get-ChildItem -Path "C:\JDEdwardsPPack\E920\PrintQueue"

What This Helps With:

• Identify active and old print jobs
• Analyze disk usage
• Support troubleshooting for UBE printing issues

2. Copying PrintQueue Files Based on Age (Retention Strategy)

In large JDE environments, old PrintQueue files need to be archived based on age.

Example: Files older than 1000 days

Get-ChildItem -Path "C:\JDEdwardsPPack\E920\PrintQueue" |
Where-Object {$_.LastWriteTime -lt (Get-Date).AddDays(-1000)} |
Copy-Item -Destination "C:\JDEdwardsPPack\E920\GoLive\PrintQueueArc"

Why This Matters:

• Prevents PrintQueue folder from growing uncontrollably
• Improves system performance
• Helps in archival strategy for compliance

3. Finding a Specific File in JDE Folder

Sometimes troubleshooting requires locating a specific report or PDF generated by JDE.

Example:

Get-ChildItem -Path "X:\JDEdwards\E920\mediaobj\htmlupload" `
-Filter "FILE-10-0-10-141-58881134646742537-1504646610815.pdf"

4. Counting Files in a JDE Folder

To understand storage usage or file volume, you can count files easily.
Example:
Get-ChildItem -Path "D:\JDEdwards\E920\mediaobj\htmlupload" -File |
Measure-Object | Select-Object -ExpandProperty Count

5. Counting Files Between Date Range
For audit or cleanup planning, filtering by date range is extremely useful.
Script:
$Path = "D:\JDEdwards\E920\mediaobj\htmlupload"      
$StartDate = "2017-01-01"
$EndDate = "2023-01-01"     

(Get-ChildItem -Path $Path -File -Recurse |
Where-Object {
    $_.CreationTime -ge $StartDate -and $_.CreationTime -le $EndDate
}).Count

6. Best Practices for JDE File Management

✔ Always Archive Before Delete

Never delete PrintQueue files directly in production without backup.

Final Thoughts

PowerShell is a powerful tool for managing JD Edwards PrintQueue and file system growth. With simple commands, administrators can:

• Analyze file usage
• Archive old print jobs
• Count media objects
• Improve system performance
• Support compliance requirements

JDE Web Package Build

 

Application 9.2

Tools Release 9.2.5.x

Verify Tools Planner ESU, Tools ESU and Tools ASI is completed

Three new applications have been delivered, off of menu GH9083, for the web client:

• P9601W - Package Assembly
• P9621W - Package Definition
• P9631W - Package Deployment

Configure Deployment Server INI

[INSTALL]

ClientType=deployment

[JDENET_KERNEL_DEF11]
KrnlName=PACKAGE BUILD KERNEL
dispatchDLLName=jdekrnl.dll
dispatchDLLFunction=_JDEK_DispatchPkgBuildMessage@28
MaxNumberOfProcesses=1
numberOfAutoStartProcesses=1

 

Also, make sure the following matches the content in the jde.ini on the Enterprise Server:

[SECURITY]
SecurityServer=xxxxxxx
User=JDE
Password=xxxxxxxx
DefaultEnvironment=DV920

[JDENET]
serviceNameListen=6017
serviceNameConnect=6017

Start and Stop Deployment Server service - JDE B9 Client Network

Set Service to Start Automatic 

Use Application P9601W to Package Assembly,followed by Define and deployment....

JDE Check-In Process Based on Tool Release

 

Tools Prior to 9.2.1

Specs - > From Dev Workstation to Central Objects (F987*) Table

Artifacts - > From Dev WorkStation source, include, java, res copied  to Deployment Server pathcode folder

Tools 9.2.1. to 9.2.4.x

Tools 9.2.1.x -> 

Specs -> From Dev Workstation to Central Objects (F987*) Table

Artifacts - > From Dev WorkStation source, include, java, res copied  to Deployment Server pathcode folder

Artifacts - > From Dev WorkStation source, include, java, res copied  to Repository F98780R and F98780H

Tools 9.2.3.x - >  

Specs -> From Dev Workstation to Central Objects (F987*) Table

Artifacts - > From Dev WorkStation source, include, java, res copied  to Deployment Server pathcode folder

Artifacts - > From Dev WorkStation source, include, java, res copied  to Repository F98780R and F98780R. 

NER and TER Artifacts not copied to Deployment Server and Repository. 

BSFN Artifacts continue copied to Deployment Server Pathcode folder

BSFN Artifacts are copied to Repository F98780R and F98780H

NER and TER Artifacts (.c and .h) are created at build time.

Tools 9.2.4.x -> 

Specs -> From Dev Workstation to Central Objects (F987*) Table

Artifacts - > From Dev WorkStation source, include, java, res copied  to Repository F98780R and F98780H. 

BSFN, NER and TER Artifacts not copied to Deployment Server.  

NER and TER Artifacts are not copied to Repository F98780R and F98780R. 

BSFN Artifacts are copied to Repository F98780R and F98780R. 

NER and TER Artifacts (.c and .h) are created at build time.

Tools 9.2.5.x or higher

E1Local Database is removed

Specs - Copied from the User Spec Tables (F98xxxUS) to the Central Objects (F987xxx) Check-in location tables.

Artifacts -> From Dev WorkStation source, include, java, res copied  to Repository F98780R and F98780H