Setting up a Deployment Site for Imaging Activities/Tasks

Products

• IT Management Suite

Issue/Introduction

You want to set up a dedicated "Deployment Site", a Site Server reserved exclusively for image capture and deployment, without that server picking up ongoing management traffic.

The typical setup that triggers this request:

1. Two Site Servers in the same LAN.
2. Both running Package and Task services.
3. Server selection configured to prefer lowest latency.
4. One server should handle deployment only, to take load off the SMP/NS and stop clients from drifting to the wrong Package or Task Server.

The new Site Server is in the same LAN as the primary SMP Server and should only run deployment jobs. Getting clients to use it consistently requires more than a latency preference.

Environment

ITMS 8.7.x, 8.8.x
Deployment Solution

Cause

When two Site Servers share a subnet, the Symantec Management Agent (SMA) picks between them using Site assignment, network latency, and internal balancing logic. LAN latency between two servers on the same segment is nearly identical — often under 1 ms — so "lowest latency" does not produce stable results. Agents drift between servers.

Site/Subnet boundary configuration is the right control, not latency preferences or firewall rules. Boundaries define which Site Server a client is eligible for. Without them, agents roam.

For imaging specifically (Deploy Image and Create Image tasks), Deployment Solution has additional controls that let you assign Package Servers directly to packages or targets. These work on top of Site configuration, not instead of it.

With two Site Servers in the same subnet and no explicit Site/Subnet boundaries in place:

• LAN latency differences are negligible and fluctuate. "Lowest latency" picks a server effectively at random.
• Agents toggle between both servers.
• Package Server and Task Server selection run on separate logic. Constraining one does not constrain the other.
• Overlapping or undefined Site/Subnet boundaries are the documented cause of sub-optimal server selection in Broadcom's own guidance.

What problems/inconveniences can arise with 2 sites (package+task Services) in the same LAN, all ports open, “lowest latency” selection?

1. Overlapping/ambiguous boundaries ⇒ unpredictable server selection

   • If both Site Servers are effectively “valid” for the same clients (same LAN/subnet), the platform may allow clients to “fail over” or pick alternates, and “lowest latency” becomes nearly meaningless because LAN latency differences are tiny and can fluctuate. Broadcom notes that overlapped/improper site boundaries and lack of constraint commonly cause sub-optimal selection.

     Non-Deterministic Behavior in Flat LAN

     Since both servers are in the same subnet:

     • Latency differences are negligible

     • Agents may toggle servers

     • "Lowest latency" becomes ineffective

     • Offloading objective may fail

2. Package Server selection can be randomized among “best candidates”

   • In ITMS 8.5 and later behavior, if you don’t explicitly force/assign, the agent can choose randomly from the best package servers based on connection statistics (not necessarily the one you intend).
     
     

     Site Server Selection Logic

     If both servers are valid candidates inside the same Site:

     The agent selects based on:

     Selection Method	Behavior	Risk
     Manual Assignment	Deterministic	Only if properly configured
     Network Cost / Latency	Compares response time	Useless in flat LAN
     Randomization	Load balancing mechanism	Agents flip between servers

3. Task Server registration and Package Server usage are not the same control

   • Even if a client is registered to a Task Server, that does not automatically dictate where packages/images come from—package assignment is driven by Subnet-to-Site and Site-to-Site Server association.

4. This is why “firewalling one side” often produces surprising results: you can “fix” TS but still see PS behavior you didn’t expect (or vice versa).
   
   

   Task vs Package Server Are Separate Decisions

   Important:

   • Task Server registration does not automatically control Package Server selection

   • Package assignment depends on Site/Subnet mapping

   This is why firewall-based enforcement often creates log errors before fallback.

 

Cause summary:

Cause	Likelihood	Evidence	Assumptions
No Site/Subnet boundary isolating deployment clients	High	Agents roam between both servers; offloading fails	Subnets not yet defined per Site
"Lowest latency" used as primary selection in flat LAN	High	LAN latency under 1 ms; selection is effectively random	Both servers on the same L2 segment
Task Server and Package Server treated as one control	Medium	Clients land on correct TS but pull packages from the wrong PS	PS assignment is subnet/site-driven, independent of TS assignment
Overlapping subnet definitions across Sites	Medium	Non-deterministic failover between servers	Existing Site definitions not audited

 

Resolution

In a flat LAN with two Site Servers in the same subnet, the Symantec Management Agent (SMA) uses Site assignment and server selection logic (manual assignment, site boundaries, latency, and internal balancing).

Because LAN latency is nearly identical (<1ms), “lowest latency” does not provide deterministic control. This can result in:

• Agents alternating between servers

• Deployment server receiving standard task traffic

• No real load reduction from NS

• Duplicate package replication

The best route in ITMS is to control which clients are eligible to use the deployment Site Server by using Site Server Management boundaries (Sites/Subnets) and (where applicable) “Constrain to Site” / assignment controls, not by relying on “lowest latency” inside the same LAN and not primarily by firewall tricks.

When two Site Servers share the same LAN/subnet, you can get non-deterministic selection (especially for Package Server) and unexpected failover behavior if boundaries overlap or are not constrained. Broadcom explicitly calls out overlapped/improper Site/Subnet definitions as a common cause of sub-optimal Package Server (PS)/Task Server (TS) selection.

Best Practice:
Use Site/Subnet boundaries to logically isolate deployment clients, and assign the Deployment Site Server exclusively to that Site.

Firewall rules or VLAN isolation can support the design — but must not replace proper Site/Subnet configuration inside ITMS.

This aligns with Broadcom guidance on Site Server selection and avoiding overlapping boundaries. ITMS selection logic is Site-driven.
If you define a Deployment Site mapped to a specific subnet, only those clients are eligible for that Site Server. This prevents wandering.

Table of Contents

• Evaluate the 3 most common ideas
  • Recommended “ideal scenario” 
  • Recommended Architecture
• Practical implementation guidance (step-by-step)
• Step-by-Step Implementation (Best Practice Design)
  • Step 1 – Create Deployment Site
  • Step 2 – Assign Deployment Subnet
  • Step 3 – Assign the Deployment Site Server
  • Step 4 – Validate Constrained Assignment
  • Step 5 – Validation on Client
• Scenario B — Firewall Rules Only (Not Recommended as Primary Control)
• Scenario C — Isolated VLAN (Strong Alternative)
• Final Recommendation

---

Evaluate the 3 most common ideas

Option	What it does	Pros	Cons	Recommendation
Dedicated/Assigned deployment subnet in ITMS	Defines which clients are eligible for the Deployment Site Server via proper boundaries	Most reliable; matches ITMS selection logic; simplest to support long-term	Requires clean Site/Subnet definitions with no overlaps	Best primary approach
Firewall rules restricting deployment traffic	Blocks agents from reaching the wrong server. Tries to enforce behavior by blocking “other” communications	Useful as a security control; Can reduce attack surface if done as allow-list	Agents retry blocked servers before failing over; produces log errors and delayed task starts	Use only as supplemental hardening, not as the control mechanism
Isolated network + deploy server only serves Deployment VLAN	Physical/logical separation of deployment devices	Clean and predictable	Still needs correct Sites/Subnets in ITMS; adds network complexity; still must define ITMS Sites/Subnets correctly or clients can attempt alternate servers when not “constrained”; more network overhead	Good if network topology allows, but Option 1 inside ITMS is still required

---

Recommended “ideal scenario” 

Make deployment eligibility boundary-based:

1. Create a dedicated Deployment Site mapped to a dedicated subnet/VLAN

   • Put only the intended deployment clients in that subnet/VLAN (even if it’s a small carve-out).
     
     Note:
     If the Deployment Site is configured using supernets or aggregated network ranges, additional configuration may be required to ensure that clients are properly associated with the site. For guidance on handling supernet scenarios when configuring a Deployment Site, see:
     How to Prevent Supernet Creation in ITMS Using the InvalidSubnets Core Setting

2. Assign that subnet to a specific ITMS “Site”

   • Ensure the subnet belongs to only one Site (avoid overlaps).

3. Assign only the deployment Site Server to that Site

   • Install only the roles you need on that Site Server (Package + Task + PXE if required).

4. Enable/validate constraint behavior

   • Ensure your configuration prevents clients from roaming to other Site Servers when they are inside that deployment subnet/site (Broadcom highlights “Constrain to Site” as a major lever to avoid non-optimal failover).

5. Optionally: remove deployment load from NS

   • Broadcom notes Task/Package services can be combined on one Site Server depending on needs (common pattern for offloading NS).

Why this is best: it aligns with how ITMS actually decides PS/TS assignment (Sites/Subnets first), and avoids relying on latency heuristics that don’t behave well when servers are in the same LAN.

 

Recommended Architecture

1. Dedicated Deployment VLAN

2. Dedicated Deployment Site in ITMS

3. Only Deployment Site Server assigned to that Site

4. Constrained assignment enabled

5. Firewall allow-list for required ports only

This ensures:

• Deterministic agent behavior

• True NS offloading

• Predictable deployment performance

• Minimal log noise

---

Practical implementation guidance (step-by-step)

1. Define Deployment VLAN/Subnet

   • Work with networking to define the subnet used for deployment endpoints only.

2. In ITMS Console: create/validate Subnet-to-Site mapping

   • Ensure the deployment subnet belongs to only one Site.

   • Avoid overlaps with existing Site definitions (this is a top cause of unexpected PS/TS choice).

3. Assign the deployment Site Server to that Site

   • Keep roles minimal (Package + Task; add PXE only if needed).

4. Constrain / prevent roaming

   • Validate settings that keep clients inside that Site using that Site Server (avoid “free failover” unless you explicitly want it).

5. Hardening (optional but recommended): restrict ports instead of “open all”

   • If you need to change/standardize Task Server client communication ports, Broadcom provides steps (and the setting is configurable).

   • Then implement firewall allow-lists based on your final ports/services, rather than broad openings.

 

Step-by-Step Implementation (Best Practice Design)

Step 1 – Create Deployment Site

1. Open SMP Console
2. Navigate to:
   Settings → Notification Server → Site Server Settings
3. In the left panel, right-click Sites.
4. Select New, then Site.
5. Name it: Deployment_Site
6. Click OK.

---

Step 2 – Assign Deployment Subnet

1. Open the Deployment_Site you just created.
2. Click the Subnets tab (add ONLY the subnet used for deployment VLAN).
3. Click Add and enter the subnet used only by deployment endpoints (for example, 192.168.10.0/24).
4. Confirm this subnet does not appear in any other Site definition.
5. Click Save changes.

NOTE: Overlapping subnets are a common root cause of wrong server selection. If the Deployment Site uses supernets or aggregated network ranges, additional steps may be needed. See: How to Prevent Supernet Creation in ITMS Using the InvalidSubnets Core Setting

---

Step 3 – Assign the Deployment Site Server

1. From Site Server Settings, find the new Site Server.
2. Move the new Site Server to Deployment_Site
3. Enable:
   • Package Service
   • Task Service
   • PXE (if required)
4. Do not assign the SMP/NS Server to Deployment_Site.
5. Click Save changes.

 

---

Step 4 – Validate Constrained Assignment

Ensure:

• Confirm clients outside Deployment_Site cannot reach the Deployment Site Server.
• Review all existing Site definitions and remove subnet overlaps.
• If "Constrain to Site" is available in your environment, enable it to stop clients from roaming when inside the deployment subnet.

---

Step 5 – Verify on a deployment client

 

1. On a client in the deployment subnet, open the Symantec Management Agent UI.
2. Check the Task Status tab. The Task Server should be the Deployment Site Server.
3. Check the Package Server tab. The Package Server should also be the Deployment Site Server, not the SMP Server or any other.

---

Controlling Package Server selection for imaging tasks

It applies specifically to Deployment Solution imaging tasks and works independently of Site/Subnet configuration. It narrows which Package Servers a client can use for imaging — it does not force a Package Server from one Site to serve a client registered in a different Site. Use it alongside proper Site boundaries, not as a substitute.

Two controls are available.

Deploy Image task: assign packages to specific Package Servers

By assigning the packages containing Ghost Images to a specific Package Server, you ensure clients download from that server during deployment.

1. Open the SMP Console.
2. Navigate to Manage, then Jobs and Tasks, then open your Deploy Image task.
3. Click the Packages tab.
4. For each package (for example, the package containing Ghost Images), click the row.
5. In the package assignment area, select the Package Server(s) that should serve this package.
6. Remove any Package Servers that should not serve this content.
7. Click Save.

Screenshot of Deploy Image task, Packages tab, showing Package Server assignment per package

Note: The example references the "Imaging" Package, which contains the Ghost tool itself, not the actual Ghost Images. Assign the correct Ghost Image packages here, not just the Ghost tool package.

Create Image task: set the default Package Server in DS Global Settings

The default Package Server for Create Image operations is set globally and applies to all capture jobs.

1. Open the SMP Console.
2. Navigate to Settings, then Deployment, then DS Global Settings.
3. Find the Default Target field. It may also appear as Default Package Server for Create Image.
4. Set this to the Package Server on your Deployment Site Server.
5. Click Save changes.

screenshot of DS Global Settings showing the Default Target field

 

Using Site configuration and imaging controls together

Site boundaries and imaging-level controls operate at different levels and cover different traffic. The table below shows what each one controls:

Layer	Mechanism	What it controls
Site/Subnet boundaries	ITMS Site Server Settings	Which server each client is eligible to use for all traffic
Package Server assignment	Deploy Image task, Packages tab	Which Package Server serves image packages during deployment
Default target	DS Global Settings	Which Package Server receives images during capture

Site boundaries cover all agent traffic. The imaging controls pin down the specific package transactions that Site selection alone does not reliably constrain.

---

Scenario B — Firewall Rules Only (Not Recommended as Primary Control)

Firewall rules as a supplemental control

Firewall rules can reduce unintended access and serve as useful hardening, but they are not a reliable primary control for server selection. Agents do not consult firewall rules when choosing a server. If a server is still marked as eligible in ITMS but blocked at the firewall, agents will attempt it first, fail, log the error, and then fall back — which causes connection failures in logs and delays task execution. Define an allow-list of required ports and treat firewall rules as hardening on top of Site/Subnet configuration, not a replacement for it.

Pros	Cons
Hard enforcement	Agents retry blocked server first
Security hardening	Causes connection failures in logs
	Delayed task execution

Agents are persistent.
If a blocked server is still "eligible", they will attempt connection before fallback.

Firewall should be used only as:

• Security hardening

• Not server selection logic

 

---

Scenario C — Isolated VLAN (Strong Alternative)

Isolated VLAN as an alternative

Isolating deployment devices in a dedicated VLAN gives clean physical or logical separation and makes server selection predictable. The tradeoff is additional routing configuration and the fact that Sites and Subnets still need to be defined correctly inside ITMS regardless. Keep the following ports open between the isolated VLAN and the SMP Server:

Port	Purpose
80 / 443	SMP Server communication
12101	Task Server

 

Pros	Cons
Physical/logical separation	Requires routing configuration
Very deterministic	Still must configure Sites properly

This is excellent if:

• You can isolate deployment devices physically

• Routing to SMP Server (80/443 + 12101) remains open

Required communication ports:

• 80/443 (SMP Server communication)

• 12101 (Task Server)
  
  

Even with VLAN isolation, you MUST still configure Site/Subnet correctly.

---

Final Recommendation

If the goal is:

“A server in the LAN dedicated only to deployment and nothing else”

Then the cleanest and most supportable design is:

✔ Subnet-based Site isolation
✔ Dedicated Deployment Site Server
✔ No overlapping subnet definitions
✔ Optional VLAN separation
✔ Firewall as hardening — not logic control

Do NOT rely on “lowest latency” inside the same LAN.

---

Verification

Check	Expected result
SMA, Task Status tab on a deployment client	Shows the Deployment Site Server
SMA, Package Server tab on a deployment client	Shows the Deployment Site Server
SMP Console, Site Server Settings	Deployment_Site has no subnet overlap with other Sites
SMP Server load during a deployment job	No increase in SMP Server package or task traffic
Deploy Image task	Packages pull from the assigned Deployment Package Server
Create Image task	Image goes to the Package Server set in DS Global Settings

If any check fails, start with Site/Subnet definitions. Overlapping subnets cause most of these failures.

Additional Information

Understanding Package and Task Server Selection Logic (Article ID 426743)

Package Server selection/assignment on ITMS 8.5 and later (Article ID 175121)

Symantec Management Agent connected to wrong Site Server (PS vs TS behavior) (Article ID 169529)

Change Task Server communication port (Article ID 178338)

How to Prevent Supernet Creation in ITMS Using the InvalidSubnets Core Setting (Article ID 432283)