Relocating you Fox dataset to a new server 

 

 1. Before you start 

 2. New server prerequisites 

 3. Back up and move the data 

 4. Antivirus / EDR exclusions 

 5. Permissions — domain security group 

 6. Scheduled tasks 

 7. Workstation reconfiguration 

8. Post-migration validation 

Trouble Shoot Guide

 

1. Before you start 

Confirm with the client: exact current server name/IP, share name, drive letter mapped on workstations, and the domain security group currently granting access. Record these — you will replicate them (or deliberately change them, see step 6) on the new server.

• Full backup: take a verified backup of the entire Ezy/Fox root folder (data, config, executables) before any file is touched. Confirm the backup restores, don't just confirm it completed.
• Notify all users to close Ezy Systems before the migration window opens — Fox tables are exclusive-lock sensitive and a mid-write copy will corrupt data.
• Confirm the new server has adequate disk, and that AntiVirus/Endpoint Detection and Response is already installed (exclusions are configured before first run, not after — see step 4).

2. New server prerequisites 

Requirement	Detail
OS	Windows Server version equal to or newer than the source server. Confirm the source server's OS/build before decommissioning it.
MS Common Controls 6.0	MSCOMCTL.OCX must be present and registered — Fox/VB front-end components depend on it. Register with: regsvr32 MSCOMCTL.OCX (run elevated Command Prompt).
Folder path	Recreate the exact same folder structure and, ideally, the same drive letter/share name as the source. If the path must change, every workstation's mapped drive and any config files referencing the old path need updating (see step 6).
File sharing	SMB share created with the same share name where possible, permissions applied per step 5.

 

 3. Back up and move the data 

1. Stop the Ezy Systems service / confirm no users are connected. Check for open file handles on the share before copying.

2. Zip the Ezy root folder on the source server - preserves attributes better than a raw network copy and gives you a single verifiable artefact for the backup.

3. Copy the zip to the new server over a wired connection where possible — not Wi-Fi — for a folder this size.

4. Extract to the target location on the new server, matching the folder structure identified in step 2 of the prerequisites above.

5. Spot-check file counts and total size against the source before proceeding — a partial copy is the most common cause of "table not found" errors after go-live.

  6. Run as administrator on the new server the first time the application is launched from that location, so Fox can complete any initial setup it needs.

 

 4. Antivirus / EDR exclusions

Add the Ezy root folder (and all subfolders) to the antivirus/EDR exclusion list on the new server before first launch. Fox tables are opened and rewritten constantly; real-time scanning causes file locking conflicts and can corrupt data mid-write.

 5. Permissions — domain security group 

Apply share and NTFS permissions at the domain group level, not to individual users — this is how Ezy Systems access should already be controlled and keeps the migration consistent with the client's existing model.

• Confirm the existing domain group used for Fox/Ezy access (e.g. DOMAIN\EzySystemsUsers — replace with the client's actual group name).
• Recreate the same NTFS + share permissions on the new server's Ezy folder: Modify for the user group, Full Control for the service/admin account if one is used.
• Do not grant Everyone or Authenticated Users — scope strictly to the domain group identified above.
• If the new server sits in a different OU or the group doesn't already have rights delegated to it, raise this with the domain admin before go-live, not during.
  
  

 

 6. Scheduled tasks

Check the source server's Windows Task Scheduler before decommissioning it — automated jobs (end-of-day processes, backups, report exports, imports/exports to other systems) live outside the Ezy folder and won't move with a file copy. Easy to miss because nothing fails immediately; it just quietly stops running.

• Audit the source server: open Task Scheduler and list every task, not just ones obviously named "Ezy" or "Fox" — check the Actions tab on each to see if it points at anything inside the Ezy root folder or calls an Ezy executable.
• Record for each task: trigger/schedule, the account it runs as, the exact command/arguments, and the working directory ("Start in").
• Recreate on the new server: don't export/import the task XML blindly if the folder path or drive letter has changed — update the action's path and working directory to match the new location first.
• Check the "run as" account: if a task runs under a specific domain service account, confirm that account has the same NTFS/share permissions on the new server (see Section 5) — a task that ran fine under the old server's local permissions can silently fail on the new one.
• Test each recreated task manually ("Run" from Task Scheduler) rather than waiting for its next scheduled trigger, so you catch path/permission issues during the migration window, not overnight.
• Leave the old tasks disabled, not deleted, on the source server until the rollback window has passed.

 7. Workstation reconfiguration 

Each workstation needs its mapped drive repointed and, on first launch, an elevated run so Fox/Ezy can write its initial local configuration.

1. Remap the network drive on each workstation to the new server path (update logon script / GPO drive mapping if one is used, rather than remapping manually on every machine where possible).

2. First launch after the move: run Ezy Systems as administrator once on each workstation. This lets the application write registry keys and local config it can't create under a standard user context — subsequent launches don't need elevation.

3. Confirm the workstation's domain account is a member of the security group from step 5 — a remapped drive with no underlying permission will show the share but fail to open the data.

4. Test opening Ezy Systems, opening a module that reads and writes data, and closing cleanly, before releasing the workstation back to the user.

Desktop icons / shortcuts

Launch Fox/Ezy from a desktop shortcut — it won't follow the drive remap automatically.

• Target: point it at the new server path — either the remapped drive letter (e.g. Z:\Vfp\vfp.exe -t ..\foxfxp\ezy) or the new UNC path if the client doesn't use mapped drives. Please note some site will have a Vfp90 instead of Vfp. check the exisiting short cut. 
• Start in (working directory): update this to match the new Ezy root folder. This is the field most people miss — Fox/Ezy often resolves its config and data paths relative to "Start in", not just the target, so a shortcut with the right target but the old "Start in" value can still fail to find tables.
• Icon file: if the shortcut's icon is sourced from a file inside the old path, it may show a blank/generic icon after the move — cosmetic only, but worth re-pointing to the icon file in the new location so it doesn't generate confused support calls.

            Fix blank Icon: Requires administrator to change Group Policy as per below link.

1. Open Group Policy Editor
2. Navigate to, Computer Configuration > Administrative Templates > Windows Components > File Explorer
3. Enable Allow the use of remote paths in file shortcut icons

• Run as administrator (if required): set this under the shortcut's Properties > Compatibility tab if the client needs the shortcut itself to always elevate, rather than relying on a one-off manual elevated launch.
• Test the shortcut itself, not just a manual launch from the exe — some issues (wrong "Start in" path) only show up via the shortcut.

 8. Post-migration validation

• Confirm file counts/sizes on the new server match the source (from step 3.5).
• Have at least one user in each department log in and perform a normal transaction end-to-end.
• Check the Windows Event Log / AV log on the new server for blocked-access events in the first hour — this surfaces missed exclusions or permission gaps quickly.
• Keep the old server and the zipped backup untouched for an agreed rollback window (recommend a minimum of 5 business days) before decommissioning.

 Troubleshooting quick reference 

Symptom	Likely cause
"Table not found" or "Path not found" on open	Folder structure or drive letter doesn't match what's referenced in Ezy config — see prerequisites, folder path.
App won't launch / missing control errors	MSCOMCTL.OCX not registered on the new server or workstation — re-run regsvr32.
Data appears to intermittently "lock up" or corrupt	AV/EDR not excluded, or exclusion scoped incorrectly — revisit step 4.
Share visible but access denied	Workstation account not in the domain group, or NTFS permissions not replicated — revisit step 5.
First-run errors only on some workstations	Elevated first run was skipped on those machines — see step 6.