How to set up a MU Online server on X-Team (X-Files)

The X-Files (X-Team files) are one of the most used server packages by those building a private MU Online, precisely because they deliver the executables already compiled and the configuration folders organized — you "only" need to point each piece to the right place. The problem is that "pointing each piece" involves the database, IPs, ports, and the correct startup order, and a single wrong value keeps the server from coming up. This tutorial walks through the complete configuration of an X-Team server from scratch: folder structure, database, the four main executables, IP/port, events, and the first boot with in-game testing. If you don't yet have the base set up, start with the MU Online server creation tutorial and come back here for the fine-tuning.

What the X-Team (X-Files) package is

X-Team is a server files repack: a set of emulators (ConnectServer, JoinServer, GameServer, DataServer) plus the Data/config folders they read at runtime. Each X-Files version is tied to a specific season (Season 6, Season X, etc.), and the player's client must be from the same season — incompatible client and server result in a frozen login screen or an immediate crash. When you download a package, always check the season, the language of the files, and whether it already comes with the database script.

Prerequisites

• Windows (Server for production; 10/11 for local testing) with administrator permission.
• SQL Server installed and accessible (Express works for testing; Standard for production), plus the SQL Server Management Studio (SSMS).
• Runtimes: Visual C++ Redistributable packages (several versions) — their absence is the #1 cause of an executable that won't open.
• The X-Files package for the desired season and the corresponding client.
• A backup of everything before editing, and a text editor that respects the files' encoding (Notepad++ is the community standard).

X-Team folder structure

The names vary by season and repack, but the backbone is usually this:

> Always work on a copy. A syntax error in any config file brings the executable down at boot, and without a backup you reinstall the entire package.

Step 1 — Prepare the database

X-Team doesn't work without the database. The typical flow:

1. Open SSMS and connect to your SQL Server instance.
2. Restore the .bak that comes with the package (Restore Database) or run the .sql scripts from the SQL/ folder to create the databases — usually MuOnline and Me_MuOnline (names vary by season).
3. Create/validate a SQL user (e.g., sa or a dedicated user) with a password, and grant access to the created databases.
4. Confirm that SQL Server (mixed) authentication is on — many packages use user/password, not Windows authentication.

Write down the instance name, user, and password: you'll repeat these three values in several config files.

Step 2 — Configure the DataServer (database connection)

The DataServer is the bridge to SQL Server. Open its configuration file (frequently DataServer.ini, MuServerDBConfig, or similar) and adjust the credentials. An example of a typical block:

[ODBC]
DBType   = 0
DBName   = MuOnline
DBUser   = sa
DBPass   = YourStrongPassword
DBServer = (local)      ; or PC-NAME\SQLEXPRESS

• DBServer is the instance name (for SQL Express it's usually .\SQLEXPRESS).
• DBName must match exactly the name of the restored database.
• Many X-Files use a Windows ODBC DSN: in that case you create the data source in the ODBC Administrator (System DSN tab) and the config references the DSN name instead of the direct IP.

Save and test: when you open the DataServer, it should log "connected to the database." If it flashes and closes, the problem is almost always a credential, database name, or DSN.

Step 3 — Configure the ConnectServer (IP and port)

The ConnectServer delivers to the client the server list and the IP/port to connect to. Locate the config file (e.g., ConnectServer.ini and/or a ServerList.dat) and set:

[ConnectServer]
ServerName = Viciados MU
MaxIpConnection = 10
CServPort = 44405

[ServerList]
; GameServerCode  IP              Port
0                 192.168.0.10    55901

• On a local network, use the internal IP (192.168.x.x).
• For the internet, use the public IP or a DDNS (No-IP, DuckDNS) — never 127.0.0.1, or only you will be able to get in.
• The default ConnectServer port is usually 44405; the GameServer's, something like 55901. They must match what the client expects.

Step 4 — Configure the JoinServer and the GameServer

The JoinServer validates login/password against the database; it usually only needs to point to the same DataServer/database — confirm the credentials and the internal port.

The GameServer is the heart of the game. In the main file (commonly GameServerInfo.dat, GameServer.ini, or GameServerInfo - VIP.dat), adjust at least:

• IP/port of the GameServer itself and the link to Connect/Data/Join.
• ServerName / ServerCode — the code must match the ServerList line in the ConnectServer.
• Experience and drop rates (see Step 6).
• Connection limit and save settings.

Point each internal address to 127.0.0.1 when everything runs on the same machine, and to the real IPs when the services are distributed.

Step 5 — Open IP and ports (firewall and router)

For external players to join:

1. In the Windows Firewall, create inbound rules opening the ConnectServer (44405) and GameServer (e.g., 55901) ports, plus any others the package uses.
2. On the router, set up port forwarding of those ports to the server's internal IP.
3. If your IP changes, set up a DDNS and use the hostname in the ConnectServer and the client.
4. In the client, edit the connection file (frequently a .dat/main encrypted per season) to point to your IP:port.

Test on LAN first; only then expose it to the internet.

Step 6 — Adjust rates and enable events

The rates and most events live in files inside the GameServer/Data. Examples of keys (names vary by season):

[Rates]
ExperienceRate = 50    ; 50x
DropRate       = 30    ; 30%
ZenDropRate    = 40

[Events]
BloodCastle   = 1
DevilSquare   = 1
ChaosCastle   = 1
GoldenInvasion= 1

• Start conservative: an absurd EXP rate empties the server for lack of progression.
• Each event has, besides the on/off switch, schedules and minimum levels in their own files (spawn/scheduler).
• Check the events' NPCs and spawns: an event turned on without an entry NPC is an event no one plays.

Step 7 — First boot in the correct order

The startup order matters, because each service depends on the previous one:

1. DataServer — comes up first and connects to the database.
2. ConnectServer — starts accepting clients.
3. JoinServer — enables login/account validation.
4. GameServer — last; registers with the ConnectServer and opens the world.

If the GameServer comes up but the client doesn't see the server in the list, it's almost always a divergence between the GameServer's ServerCode and the ConnectServer's ServerList, or a wrong IP/port.

Step 8 — Test in-game

1. Open the client pointed at your IP:port and reach the login screen.
2. Create an account (registration writes to the database via JoinServer/DataServer) and log in.
3. Create a character, enter the world, and walk — confirm that the GameServer responds.
4. Level up and validate the configured EXP/drop rates.
5. Enter with a GM and trigger an event (e.g., Blood Castle) to confirm the scheduler and NPCs.
6. Check each executable's logs for silent errors.

Common errors and fixes

Launch checklist

• SQL Server active, databases restored, and mixed SQL authentication on.
• DataServer connecting to the database (log "connected").
• ConnectServer with public IP/DDNS and correct ServerList.
• JoinServer validating login and creating accounts.
• GameServer with aligned ServerCode, correct rates and IPs.
• Ports opened in the firewall and router (port forwarding).
• Client from the same season pointed to the right IP:port.
• Boot order tested (Data → Connect → Join → Game).
• Events turned on, with validated schedules and NPCs.
• Complete in-game test (account, character, EXP/drop, event).
• Backup of the database and the configs saved before opening to the public.

With the server online and tested on LAN, the final step is "hardening" it for production: strong passwords in SQL, a dedicated database user (not sa), automatic database backups, and monitoring of the executables for automatic restart in case of a crash. From there, each new season or X-Team repack follows the same pipeline — only the key names and the client version change, which you treat as examples to confirm, because everything varies by emulator.

Frequently asked questions