How to set up a MU Online server on the IGCN emulator

Setting up a MU Online server on IGCN is, in practice, orchestrating five pieces that must talk to each other in the right order: an SQL Server with the databases restored, the DataServer (which talks to the database), the ConnectServer (the client's entry point), the JoinServer (account authentication), and the GameServer (the world itself). If any of these pieces is pointing to the wrong IP, port, or password, the stack comes up halfway and the player gets stuck on the login screen. This tutorial walks through the complete installation and configuration of IGCN — from the database to the first character in the game — highlighting where the values change from build to build. Before diving in, if you don't yet have the foundation set up, check out the MU Online server creation tutorial, which covers the general concepts we'll apply here to IGCN specifically.

What the IGCN emulator is

IGCN is one of the most widely used emulators (or "MuServer") in the history of MU private servers. It reimplements the logic of the official servers, letting you run your own MU without Webzen's binaries. A typical IGCN build comes organized into folders by service — usually something like ConnectServer, DataServer, JoinServer, and GameServer (or MuServer\...), each with its executable and its .dat/.txt configuration files. The most widespread IGCN season in the community is Season 6, but builds for other versions exist. The golden rule: client and emulator must be from the same season.

Prerequisites

• Windows (Server or Desktop) with administrator privileges.
• SQL Server installed (2008/2012/2014 usually work painlessly) and the SQL Server Management Studio (SSMS).
• Visual C++ Redistributables (several versions — IGCN usually requires 2010/2013/2015 depending on the build).
• The IGCN build with the databases (.bak or .sql scripts) included.
• A MU client compatible with the emulator's season.
• Basic knowledge of firewall and port forwarding, if you're going to open it externally.
• A backup of everything before editing any file.

Architecture: the pieces and the startup order

Each service has a responsibility and a dependency. Always bring them up in this order:

Reversing this order is the #1 cause of "the GameServer opens and closes on its own." Without the DataServer up, nobody talks to the database.

Step 1 — Prepare SQL Server and restore the databases

1. Install SQL Server in mixed mode (SQL Server and Windows Authentication) and set a password for the sa user. Write that password down — it goes into several .dat files.
2. Open SSMS and connect to the local instance (e.g., .\SQLEXPRESS or localhost).
3. Restore the databases that come with the build. Usually there are two: the main one (frequently called MuOnline) and a ranking/events one (name varies by build). Use Restore Database pointing to the .bak files, or run the provided .sql scripts.

-- Restore example (the file name and path vary by build)
RESTORE DATABASE MuOnline
FROM DISK = N'C:\MuServer\DB\MuOnline.bak'
WITH REPLACE, RECOVERY;

1. Confirm that the sa login is enabled (Security → Logins → sa → Status → Enabled) and that TCP/IP is active in the SQL Server Configuration Manager. Without TCP/IP enabled, the DataServer won't connect.

> The database names and the sa password are common examples — each IGCN build may use different names and passwords. Check your build's README.

Step 2 — Install dependencies and check the ODBC/DSN

Many IGCN builds connect to the database via DSN (ODBC). If yours is one of them:

1. Open the ODBC Data Source Administrator (search for odbcad32). On 32-bit builds, use the odbcad32 from the SysWOW64 folder.
2. Create a System DSN (e.g., named MuOnline) pointing to your SQL instance, with SQL Server authentication (sa login + password).
3. Test the connection inside the wizard itself. If it fails here, it will fail in the emulator.

Also install the required Visual C++ Redistributables. A classic symptom of a missing VC++ is the executable not even opening, or closing without a message.

Step 3 — Configure the DataServer

The DataServer is the one that actually talks to the database. In its configuration file (names vary: DataServer.dat, MuOnline.dat, IGC_DataServer.txt, etc.), you define the connection to SQL. A typical block:

[Database]
ODBC_Name   = MuOnline
DB_User     = sa
DB_Password = yourPasswordHere
Port        = 55960

• ODBC_Name must match exactly the DSN created in step 2 (or the database name, depending on the build).
• DB_Password is the sa password.
• The Port is the one the other services use to find the DataServer — write it down.

Bring the DataServer up and verify in its console the successful database connection message. Only proceed once it's stable.

Step 4 — Configure the ConnectServer and the server list

The ConnectServer is the entry point: the client connects to it first and receives the server list. Two things matter here:

1. Listening port — the port the client hits (commonly something like 44405, but it varies by build). It needs to match the client's .dat (more on this in Step 7).
2. Server list — a file (e.g., ServerList.dat) where you define the displayed GameServers, each with an IP and a port.

; ServerList.dat (example — format varies by build)
; ServerName  ServerCode  IP            Port
Servidor01     0           127.0.0.1     55901

For local testing, use 127.0.0.1. To open it to the public, use the machine's external IP (or No-IP domain). A classic mistake is leaving 127.0.0.1 in the list and then wondering why no one from outside can get in.

Step 5 — Configure the JoinServer

The JoinServer handles account authentication — it validates username and password against the database (via DataServer). In its configuration, the essential thing is to point to the correct DataServer:

[JoinServer]
DataServerIP   = 127.0.0.1
DataServerPort = 55960
JoinPort       = 55970

• DataServerIP/DataServerPort must point to the DataServer from Step 3.
• JoinPort is the port the GameServer uses to talk to the JoinServer.

Bring the JoinServer up and confirm in the console that it connected to the DataServer. If it keeps reconnecting in a loop, the DataServer's IP/port is wrong or the DataServer is down.

Step 6 — Configure the GameServer

The GameServer is the playable world. It depends on DataServer and JoinServer. In the configuration files (names vary: GameServerInfo.dat, IGC_GameServer.txt, GameServer.dat), the critical fields are:

Beyond the connections, this is where you begin to customize the server: EXP and drop rates, reset limits, events, and so on — but only after the stack is up and logging in. Bring the GameServer up last. If it connects and drops, review DataServer/JoinServer (order and IP/port).

Step 7 — Configure the client and the connection main/.dat

On the client side, the player needs to point to your ConnectServer. Depending on the season, this is done by editing a connection file (frequently encrypted — e.g., a .dat read by main.exe) with the ConnectServer's IP and port:

; Conceptual example — the real format is usually encrypted
IpAddress = 127.0.0.1
Port      = 44405

Practical rules:

1. The port here must be the same as the ConnectServer's (Step 4).
2. For local testing, 127.0.0.1; for the public, the external IP/domain.
3. Client and emulator must be from the same season, or the client crashes at login.
4. If your build uses a launcher with file verification, generate/update the hash list after editing the client.

Step 8 — Firewall, ports, and external IP

For outside players to join, open the ports used — typically the ConnectServer's and each GameServer's — in the Windows Firewall and, if you're behind a router, set up port forwarding to the machine's internal IP.

# Example: open the ConnectServer port in the Windows Firewall (adjust the port)
netsh advfirewall firewall add rule name="MU ConnectServer" dir=in action=allow protocol=TCP localport=44405

Without a static IP, use a dynamic DNS service (No-IP/DuckDNS) and put the domain in the ServerList and the client. Never expose the SQL Server port (1433) to the internet — keep the database accessible only locally.

Step 9 — First in-game login test

1. Bring the stack up in order: SQL → DataServer → ConnectServer → JoinServer → GameServer.
2. Check that each console showed a successful connection (no reconnection loops).
3. Open the client, create an account (registration may be via web/tool or directly in the database, depending on the build).
4. Log in: you should see the server list (ConnectServer OK) and be able to enter the world (JoinServer + GameServer OK).
5. Create a character and walk a few steps — if the char appears and the map loads, your stack is healthy.

Common errors and fixes

Launch checklist

• SQL Server in mixed mode, sa enabled, and TCP/IP active.
• Databases restored and DSN/ODBC tested successfully.
• VC++ Redistributables installed.
• DataServer connected to the database (clean console).
• ConnectServer with the correct port and ServerList configured.
• JoinServer pointing to the right DataServer.
• GameServer with ServerCode, IPs, and ports matching the rest.
• Client from the same season pointing to the ConnectServer.
• Firewall/router opened (Connect and Game ports); SQL closed to the outside.
• Login, account creation, and world entry tested end to end.
• Backup of the database and the MuServer folder before opening to the public.

With the stack up and the first login working, the heavy infrastructure work is done — from here on it's project tuning: EXP and drop rates, events, resets, item systems, and your server's economy. Document every port, IP, and password in an internal file (outside the public client): when the server grows and you move the database to another machine, this connection map is what saves you hours of headaches.

Frequently asked questions