Exchange’s transport queue contains mail that has been accepted but not yet delivered. Moving its database is therefore not a tidy-up operation. A careless path edit can start an empty queue at the new location while the undelivered messages remain in an abandoned Mail.que file.

Microsoft supplies a script for moving all related transport-storage paths together. Use the current script shipped with the installed Exchange build and plan the operation around message continuity, not just free disk space.

Know what is being moved

Exchange Server stores all queues on a Mailbox or Edge Transport server in one ESE queue database. The configuration also controls separate locations for:

  • the queue database;
  • queue transaction logs;
  • the IP filter database;
  • IP filter transaction logs; and
  • transport temporary storage.

The supplied Move-TransportDatabase.ps1 script expects all five paths. Treat them as one reviewed configuration even if some destinations remain unchanged.

This is not the mailbox database, message-tracking logs, protocol logs or content-index data. Inventory those separately before changing storage.

Decide whether to preserve the current queue

Changing the configured path and restarting Transport without moving the files creates a new empty queue database. That may be acceptable only when the old queue contains no mail that must survive.

If undelivered mail matters, preserve and move the existing queue database through Microsoft’s documented process while the Exchange Transport service is stopped. Before the outage capture:

  • queue counts by type and status;
  • representative synthetic message identities;
  • retry and next-hop state;
  • poison and shadow/redundancy conditions;
  • current database/log file paths and sizes; and
  • current transport-service and mail-flow health.

Do not freeze a message queue full of unresolved poison, loop or downstream-delivery problems and call the storage move successful. Resolve or explicitly accept the incident state first.

Prepare the destination

Choose local storage that meets the installed Exchange version’s support and performance requirements. Record filesystem, capacity, expected growth, monitoring thresholds, backup/security tooling interaction and the failure domain shared with other Exchange data.

Microsoft’s procedure requires Full Control for Network Service, System and Administrators on the queue/log folder. Apply only the required local permissions and verify inheritance on the exact path. Do not use a general user share or grant broad interactive access to queued message data.

Ensure there is room for:

  • the present queue and logs;
  • peak retry backlog during a downstream outage;
  • temporary message conversion/scanning work;
  • the working copy during relocation; and
  • rollback retention until acceptance.

Add storage and queue thresholds to monitoring before the change so the new path cannot fill silently.

Plan the interruption and mail-flow behaviour

Stopping or restarting the Exchange Transport service interrupts mail flow on that server. Drain or redirect new connections according to the topology, and confirm that redundant servers can carry the load. If this is the only transport path, arrange an approved mail-flow interruption rather than pretending it is online work.

Record:

  • maintenance start and maximum duration;
  • upstream/downstream retry behaviour;
  • load balancer or DNS handling;
  • service stop/start sequence;
  • expected old and new file inventory;
  • rollback trigger and commands; and
  • who decides whether queued mail may be discarded.

Use the version-shipped move script

From the installed Exchange Scripts directory, inspect the current Move-TransportDatabase.ps1 help and parameters. Supply explicit local paths for all five settings. Do not use an internet copy from a different Exchange build.

The operation will stop and restart Transport as part of moving the configured data. Keep the console output and service events. If the script stops part-way, do not improvise by mixing files between old and new locations; preserve both states and use the recorded rollback or escalate.

For a manual operation, Microsoft’s current procedure requires the Transport service to be stopped while the existing queue database and logs are moved. Editing EdgeTransport.exe.config alone does not move them. Prefer the supplied script unless a documented build-specific reason requires the manual path.

Verify files and configuration

After Transport starts, verify the effective configuration and the complete file set at the intended destinations. For the queue database this includes Mail.que, its checkpoint and the transaction/reserve files described by Microsoft.

Do not assume that a created folder proves Exchange is using it. Confirm:

  • the active Transport process has opened files at the new paths;
  • timestamps and file growth occur in the intended location;
  • the service remains running without new ESE, permission or disk errors;
  • queue enumeration returns the expected queues and messages; and
  • no new active queue database has appeared at a default or partial path.

For temporary storage, submit synthetic mail that exercises the organisation’s normal transport agents and attachment handling. Confirm temporary files appear, are released and are cleaned from the intended path. A basic text message may not exercise that path.

Prove that no mail was abandoned

Compare the pre-change and post-change queue inventory. Account for messages that were delivered, retried, rejected or expired during the maintenance window. Use synthetic messages with known identities to prove each expected route.

Test:

  • inbound and outbound Internet mail;
  • internal mailbox-to-mailbox delivery;
  • application/SMTP relay paths;
  • Edge-to-Mailbox transport if present;
  • transport rules, malware/security agents and journaling where applicable; and
  • delivery after a deliberately temporary downstream failure.

A Transport service in Running state proves only that the service started. It does not prove queue continuity or end-to-end delivery.

Retain rollback evidence before cleanup

Keep the original queue files inaccessible to the active service but recoverable until the queue comparison and mail-flow tests pass. Record their hashes, sizes and retention deadline.

Only then remove the old copy under the approved data-handling process. If unexplained messages remain in an old queue database, preserve it and escalate; Microsoft provides specialised recovery guidance for old queue databases in some crash scenarios, and blind deletion can make those messages unrecoverable.

Make the change survive servicing

Exchange cumulative updates overwrite custom settings in XML application configuration files, including EdgeTransport.exe.config. Preserve a secure configuration record and add a post-CU check that compares the effective five transport paths with the approved design.

Do not automatically copy an old configuration file over a newer CU version. Reapply only the intended settings to the new file and re-run service, queue and mail-flow verification.

Acceptance checklist

The relocation is complete only when:

  • all five approved paths match the effective configuration;
  • required files are active at the new locations;
  • service and storage logs are clean;
  • every pre-change queued message is accounted for;
  • representative mail-flow and temporary-storage tests pass;
  • monitoring and capacity alerts cover the new volumes;
  • rollback copies are retained until the agreed deadline; and
  • the CU reapplication/check procedure is documented.

Disk space is the reason to plan the change. Proven message continuity is the reason to accept it.