380 000 ₽ в год на лицензии: миграция типографии с Windows на Linux

Задача клиента: типография хочет избавиться от лицензий Microsoft

К нам обратилась типография «ПринтПро» из Нижнего Новгорода — 60 человек в штате: дизайнеры, операторы печатного оборудования, менеджеры, администрация. Каждый год компания отдавала Microsoft больше 400 000 рублей только за продление лицензий. И в какой-то момент руководство задало нам прямой вопрос: реально ли уйти на Linux и при этом ничего не сломать?

Почему клиент вообще решился на миграцию:

  • Экономия на лицензиях — Windows Server 2022 Standard обходится примерно в 80 000 руб., плюс CAL на каждого пользователя по ~5 000 руб. На 60 человек набегает 380 000+ руб. И это только лицензии, без поддержки
  • Стабильность — Windows-сервер уходил на перезагрузку ради обновлений почти каждую неделю. В производственной компании это ощутимо
  • Производительность — Linux потребляет заметно меньше RAM при той же нагрузке. На слабом железе разница особенно заметна
  • Безопасность — типография уже дважды поймала шифровальщика. Оба раза с последствиями

Риски, о которых мы честно предупредили клиента сразу:

  • Совместимость ПО — 1С и специализированное ПО для вёрстки требовали отдельной проработки
  • Переобучение персонала — системному администратору пришлось бы плотно погрузиться в Linux. Это время и усилия
  • Потеря функционала AD — полноценно заменить Group Policy не получится, часть политик придётся реализовывать иначе
  • Длительность проекта — мы оценили реалистично: 3–4 месяца при параллельной работе инфраструктуры

Финансы — это одно. Но по-настоящему клиента допекала безопасность. За год типография дважды поймала шифровальщика. Первый раз отделались испугом — подняли данные из бэкапа, потеряли два дня работы. Второй раз бэкап не спас: пришлось платить выкуп. Итого больше 500 000 рублей ущерба за год. Linux в этом смысле — не серебряная пуля, но шифровальщики под него практически не пишутся. Это факт, который сложно игнорировать.

Типография работала в две смены. Простой сервера даже на пару часов — это остановка производства и сорванные заказы. Именно поэтому мы сразу отказались от идеи «выключили старое, включили новое». Только поэтапная миграция: на каждом шаге старая и новая инфраструктуры работают параллельно, и для каждого этапа заранее прописан план отката.

Проведённый аудит инфраструктуры

Сначала мы запустили аудиторские скрипты прямо на контроллере домена клиента — нужно было понять, что вообще крутится в инфраструктуре:

# PowerShell: Экспорт ролей сервера
Get-WindowsFeature | Where-Object {$_.Installed -eq $true} | 
  Export-Csv -Path C:\audit\server_roles.csv -NoTypeInformation

# Список пользователей AD
Get-ADUser -Filter * -Properties * | 
  Select-Object Name, SamAccountName, Department, Enabled, LastLogonDate |
  Export-Csv -Path C:\audit\ad_users.csv -NoTypeInformation -Encoding UTF8

# Группы и членство
Get-ADGroup -Filter * | ForEach-Object {
  $group = $_.Name
  Get-ADGroupMember -Identity $_ | ForEach-Object {
    [PSCustomObject]@{Group=$group; Member=$_.Name; Type=$_.objectClass}
  }
} | Export-Csv -Path C:\audit\ad_groups.csv -NoTypeInformation

# Общие папки
Get-SmbShare | Where-Object {$_.Special -eq $false} | ForEach-Object {
  $share = $_.Name
  Get-SmbShareAccess -Name $share | ForEach-Object {
    [PSCustomObject]@{Share=$share; Account=$_.AccountName; Access=$_.AccessRight}
  }
} | Export-Csv -Path C:\audit\shares.csv -NoTypeInformation

# GPO
Get-GPO -All | Select-Object DisplayName, GpoStatus, CreationTime |
  Export-Csv -Path C:\audit\gpo_list.csv -NoTypeInformation

# DNS и DHCP
Get-DnsServerResourceRecord -ZoneName "company.local" |
  Export-Csv -Path C:\audit\dns_records.csv -NoTypeInformation

Get-DhcpServerv4Scope | Export-Csv -Path C:\audit\dhcp_scopes.csv -NoTypeInformation

По результатам аудита собрали таблицу: что заменяем, на что, в какой очерёдности:

Сервис WindowsТекущий серверЗамена на LinuxСложность
Active DirectoryDC01FreeIPA / Samba ADВысокая
Файловый серверFS01SambaСредняя
DNSDC01BIND9Низкая
DHCPDC01ISC DHCPНизкая
Принт-серверFS01CUPS + SambaСредняя
Почтовый серверMAIL01Postfix + DovecotВысокая
МониторингZabbixНизкая

Выбор дистрибутива

Дистрибутив выбирали осознанно. Остановились на Debian 12 — вот почему:

ДистрибутивПоддержкаПреимуществаДля кого
Debian 125 лет (LTS)Стабильность, минимализмУниверсальный выбор
Ubuntu Server 24.04 LTS10 летМного документацииНачинающие
AlmaLinux 910 летСовместимость с RHELКорпоративная среда
Astra Linux SEБессрочнаяСертификация ФСТЭКГос. организации

Для производственной среды типографии Debian 12 оказался оптимальным выбором: максимальная стабильность, минимальный overhead, и документации по нему — море. Администратор не останется один на один с проблемой.

Замена Active Directory: FreeIPA и Samba AD DC

Active Directory держала на себе всю инфраструктуру типографии: аутентификацию, политики, доступ к ресурсам. Это была самая болезненная часть миграции — и мы это понимали с самого начала.

Замена Active Directory — то место, где чаще всего ломаются миграции. Мы не торопились. Развернули FreeIPA рядом с живым контроллером домена Windows, настроили trust между ними и начали переключать сервисы по одному. Старый Windows DC не трогали весь проект и ещё 30 дней после финального переключения — просто на случай, если что-то всплывёт.

FreeIPA для управления пользователями

В качестве замены AD выбрали FreeIPA — там из коробки идут LDAP, Kerberos, DNS, веб-интерфейс и поддержка trust с AD для параллельной работы. Вот как разворачивали:

# Установка FreeIPA
sudo apt update
sudo apt install -y freeipa-server freeipa-server-dns

# Настройка
sudo ipa-server-install \
  --realm=COMPANY.LOCAL \
  --domain=company.local \
  --ds-password=DirectoryManagerPassword \
  --admin-password=AdminPassword \
  --hostname=ipa.company.local \
  --setup-dns \
  --forwarder=8.8.8.8 \
  --no-ntp

kinit admin
ipa user-find
ipa group-find

Подключение Linux-клиентов к FreeIPA:

sudo apt install -y freeipa-client

sudo ipa-client-install \
  --server=ipa.company.local \
  --domain=company.local \
  --realm=COMPANY.LOCAL \
  --principal=admin \
  --password=AdminPassword \
  --mkhomedir \
  --enable-dns-updates

Миграция учётных записей пользователей из AD:

#!/bin/bash
# migrate_users.sh
while IFS=, read -r name login department; do
  ipa user-add "$login" \
    --first="$(echo $name | cut -d' ' -f1)" \
    --last="$(echo $name | cut -d' ' -f2)" \
    --department="$department" \
    --password
done < ad_users.csv

Samba AD DC для Windows-рабочих станций

Часть рабочих станций в типографии осталась на Windows — никуда не денешься. Для них дополнительно подняли Samba в режиме контроллера домена:

# Установка Samba AD DC
sudo apt install -y samba samba-dsdb-modules samba-vfs-modules \
  winbind libpam-winbind libnss-winbind krb5-config krb5-user

sudo systemctl stop smbd nmbd winbind
sudo systemctl disable smbd nmbd winbind
sudo rm /etc/samba/smb.conf

# Создание домена
sudo samba-tool domain provision \
  --use-rfc2307 \
  --realm=COMPANY.LOCAL \
  --domain=COMPANY \
  --server-role=dc \
  --dns-backend=SAMBA_INTERNAL \
  --adminpass='StrongAdminPass123!'

sudo cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
sudo systemctl unmask samba-ad-dc
sudo systemctl enable --now samba-ad-dc

Проверка:

host -t SRV _ldap._tcp.company.local localhost
host -t SRV _kerberos._tcp.company.local localhost
kinit administrator@COMPANY.LOCAL
samba-tool user list
samba-tool group list

# Создание пользователя
samba-tool user create ivanov 'Password123!' \
  --given-name=Иван --surname=Иванов \
  --department=IT

Сравнивали варианты так:

КритерийFreeIPASamba AD DC
Windows в доменеОграниченноПолная поддержка
Group PolicyНетОграниченно
Веб-интерфейсДаЧерез RSAT
Sudo-правилаДаНет
PKIВстроенный CAНет

Миграция файлового сервера и принтеров

Файловый сервер — пожалуй, самая спокойная часть миграции. 2 ТБ проектных файлов, разветвлённые права доступа, и задача одна: перенести всё это так, чтобы никто ничего не потерял и не заметил склейки.

2 ТБ данных переносили в два захода. Первую полную синхронизацию сделали в выходные, пока типография стояла. Потом неделю оба сервера работали параллельно: люди работали со старым, мы каждый день синхронизировали дельту на новый. В день переключения финальная синхронизация заняла 15 минут. Переключили UNC-пути — и всё. Народ вернулся с обеда и продолжил работать. Большинство вообще ничего не заметили.

Перенос общих папок с сохранением прав

Последовательность переноса данных выглядела так:

# Шаг 1: Подготовка структуры
sudo mkdir -p /srv/samba/{shared,accounting,management,projects,homes}
sudo apt install -y samba acl rsync
# Шаг 2: Перенос данных
# С Windows-стороны
robocopy \\OLDSERVER\shared \\NEWSERVER\shared /E /COPY:DAT /R:3 /W:5 /MT:8 /LOG:C:\migration_shared.log

# Или с Linux через CIFS
sudo apt install -y cifs-utils
sudo mkdir /mnt/windows_share
sudo mount -t cifs //OLDSERVER/shared /mnt/windows_share -o username=admin,password=pass,iocharset=utf8
sudo rsync -avz --progress /mnt/windows_share/ /srv/samba/shared/

# Финальная синхронизация
sudo rsync -avz --delete /mnt/windows_share/ /srv/samba/shared/
# Шаг 3: Воссоздание прав
#!/bin/bash
# set_permissions.sh
sudo chown -R root:domain_users /srv/samba/shared
sudo chmod -R 2775 /srv/samba/shared

sudo chown -R root:accounting /srv/samba/accounting
sudo chmod -R 2770 /srv/samba/accounting

sudo setfacl -R -m g:management:rx /srv/samba/accounting
sudo setfacl -R -d -m g:management:rx /srv/samba/accounting

for project_dir in /srv/samba/projects/*/; do
  project=$(basename "$project_dir")
  if getent group "project-$project" >/dev/null; then
    sudo setfacl -R -m g:"project-$project":rwx "$project_dir"
    sudo setfacl -R -d -m g:"project-$project":rwx "$project_dir"
  fi
done

Перенос принтеров на CUPS

В типографии пять принтеров разного формата — от настольных до широкоформатных. Всех перевели на CUPS:

sudo apt install -y cups cups-filters printer-driver-all hplip
sudo cupsctl --remote-admin --share-printers
sudo usermod -aG lpadmin admin

# Добавление принтеров
sudo lpadmin -p HP-LaserJet-M404 -E \
  -v socket://192.168.1.200:9100 \
  -m everywhere \
  -o printer-is-shared=true

sudo lpadmin -p Kyocera-ECOSYS -E \
  -v ipp://192.168.1.201/ipp/print \
  -m everywhere \
  -o printer-is-shared=true

lpstat -p -d

Настройка Samba для расшаривания принтеров на Windows-клиенты:

[global]
   printing = cups
   printcap name = cups
   load printers = yes

[printers]
   comment = All Printers
   path = /var/spool/samba
   printable = yes
   browseable = no
   valid users = @"COMPANY\Domain Users"

DNS, DHCP и замена групповых политик

Инфраструктурные сервисы переехали без особых сюрпризов — там всё предсказуемо. Сложнее было с групповыми политиками: полного аналога GP в Linux нет, но рабочие альтернативы мы нашли.

DNS и DHCP мигрировали первыми — риски минимальные, логика очевидна. Подняли BIND9 и ISC DHCP параллельно с Windows-аналогами, прогнали неделю тестирования в боевой сети. Когда переключили DNS-резолверы в DHCP на новый сервер, клиенты сами начали уходить на Linux DNS по мере обновления аренды — без какого-либо ручного вмешательства. Ещё неделю смотрели на графики и логи: все DNS-запросы отрабатывали корректно, обратные зоны поднялись, SRV-записи для Kerberos тоже встали как надо.

DNS-сервер (BIND9)

Замена Windows DNS:

sudo apt install -y bind9 bind9-utils
# /etc/bind/named.conf.local
zone "company.local" {
    type master;
    file "/etc/bind/db.company.local";
    allow-update { key rndc-key; };
};

zone "1.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.1";
    allow-update { key rndc-key; };
};
# /etc/bind/db.company.local
$TTL 86400
@   IN  SOA ns1.company.local. admin.company.local. (
        2026033101  ; Serial
        3600        ; Refresh
        1800        ; Retry
        604800      ; Expire
        86400 )     ; Minimum TTL

@       IN  NS      ns1.company.local.
@       IN  A       192.168.1.10
ns1     IN  A       192.168.1.10
ipa     IN  A       192.168.1.10
fs      IN  A       192.168.1.11
mail    IN  A       192.168.1.12
zabbix  IN  A       192.168.1.13

_ldap._tcp      IN SRV  0 100 389 ipa.company.local.
_kerberos._tcp  IN SRV  0 100 88  ipa.company.local.
_kpasswd._tcp   IN SRV  0 100 464 ipa.company.local.
_kerberos       IN TXT  "COMPANY.LOCAL"
sudo named-checkconf
sudo named-checkzone company.local /etc/bind/db.company.local
sudo systemctl enable --now named

DHCP-сервер

Замена Windows DHCP:

sudo apt install -y isc-dhcp-server
# /etc/dhcp/dhcpd.conf
authoritative;

option domain-name "company.local";
option domain-name-servers 192.168.1.10;
option ntp-servers 192.168.1.10;
default-lease-time 28800;
max-lease-time 86400;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.250;
    option routers 192.168.1.1;
    option broadcast-address 192.168.1.255;
}

host printer-hp {
    hardware ethernet 00:1a:2b:3c:4d:5e;
    fixed-address 192.168.1.200;
    option host-name "printer-hp";
}

host printer-kyocera {
    hardware ethernet 00:5e:4d:3c:2b:1a;
    fixed-address 192.168.1.201;
    option host-name "printer-kyocera";
}

subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.200;
    option routers 192.168.10.1;
    option domain-name-servers 8.8.8.8, 8.8.4.4;
    default-lease-time 3600;
}
nano /etc/default/isc-dhcp-server
INTERFACESv4="eth0"

sudo systemctl enable --now isc-dhcp-server

Альтернативы групповым политикам

Для каждой GPO-задачи нашли рабочую замену на Linux — ни одну функцию не выкинули просто так:

GPO-задачаLinux-альтернативаИнструмент
Подключение дисковАвтомонтированиеPAM + autofs
Установка ПОЦентрализованное управлениеAnsible
БезопасностьSudo-правилаFreeIPA HBAC
Ограничение USBudev-правилаudev + Ansible
Обновленияunattended-upgradesAnsible + cron

Пример sudo-правил в FreeIPA:

ipa sudorule-add allow_reboot --desc="Разрешить перезагрузку"
ipa sudorule-add-user allow_reboot --groups=sysadmins
ipa sudorule-add-host allow_reboot --hostgroups=all_servers
ipa sudorule-add-runasuser allow_reboot --users=root
ipa sudorule-add-allow-command allow_reboot --sudocmds=/sbin/reboot
ipa sudorule-add-allow-command allow_reboot --sudocmds=/sbin/shutdown

Миграция почтового сервера

У типографии был Exchange Server на 60 ящиков. Переехали на Linux-стек.

Перенос 60 ящиков с Exchange на Postfix + Dovecot — это не «просто настроить сервер». Почта для типографии критична: потеря даже одного письма с макетом или согласованием заказа — это уже скандал с клиентом. Поэтому планировали каждый шаг.

Стек Postfix + Dovecot + Rspamd

Развернули стандартный почтовый стек:

sudo apt install -y postfix dovecot-imapd dovecot-lmtpd rspamd redis-server

sudo postconf -e "myhostname = mail.company.ru"
sudo postconf -e "mydomain = company.ru"
sudo postconf -e "mydestination = \$myhostname, localhost.\$mydomain, localhost, \$mydomain"
sudo postconf -e "mynetworks = 127.0.0.0/8 192.168.1.0/24"
sudo postconf -e "smtpd_tls_cert_file = /etc/letsencrypt/live/mail.company.ru/fullchain.pem"
sudo postconf -e "smtpd_tls_key_file = /etc/letsencrypt/live/mail.company.ru/privkey.pem"
sudo postconf -e "smtpd_use_tls = yes"
sudo postconf -e "mailbox_transport = lmtp:unix:private/dovecot-lmtp"

Миграция ящиков через imapsync:

sudo apt install -y imapsync

# Перенос одного ящика
imapsync \
  --host1 exchange.company.local --user1 ivanov@company.ru --password1 'OldPass' \
  --host2 mail.company.ru --user2 ivanov@company.ru --password2 'NewPass' \
  --ssl1 --ssl2 \
  --exclude 'Junk|Spam'

# Массовый перенос
#!/bin/bash
while IFS=, read -r email old_pass new_pass; do
  echo "Migrating $email..."
  imapsync \
    --host1 exchange.company.local --user1 "$email" --password1 "$old_pass" \
    --host2 mail.company.ru --user2 "$email" --password2 "$new_pass" \
    --ssl1 --ssl2 \
    --exclude 'Junk|Spam' \
    --log --logdir /var/log/imapsync/
done < mailboxes.csv

DNS-записи для почты

Обновили DNS-записи:

# MX-запись
company.ru.   IN  MX  10  mail.company.ru.

# A-запись
mail.company.ru.  IN  A  EXTERNAL_IP

# SPF
company.ru.   IN  TXT  "v=spf1 mx ip4:EXTERNAL_IP -all"

# DKIM
mail._domainkey.company.ru.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

# DMARC
_dmarc.company.ru.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:postmaster@company.ru"

Мониторинг и план отката

После каждой фазы мы держали под контролем новую инфраструктуру и не спешили гасить Windows — откат должен был оставаться реальным вариантом, а не просто словами в презентации.

Внедрение мониторинга Zabbix

Поставили Zabbix для контроля всех сервисов:

wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
sudo dpkg -i zabbix-release_latest_7.0+debian12_all.deb
sudo apt update
sudo apt install -y zabbix-server-pgsql zabbix-frontend-php \
  zabbix-nginx-conf zabbix-agent2 zabbix-sql-scripts postgresql

Что мониторили после миграции в первую очередь:

  • Доступность FreeIPA, Samba, DNS, DHCP, Mail
  • Время отклика файлового сервера
  • Аутентификация — успешные и неуспешные попытки
  • Дисковое пространство и I/O
  • Количество активных сессий Samba

План миграции по фазам и откат

Миграцию делали поэтапно — никакого «большого взрыва» в выходные:

ФазаСрокЗадачиРиск отката
1. ПодготовкаНедели 1-2Аудит, установка LinuxНулевой
2. DNS + DHCPНеделя 3Параллельный запускНизкий
3. Файловый серверНедели 4-5Перенос 2 ТБ данныхСредний
4. Каталог (AD)Недели 6-8FreeIPA/Samba ADВысокий
5. ПочтаНедели 9-11Перенос 60 ящиковВысокий
6. МониторингНеделя 12Zabbix + дашбордыНулевой
7. СтабилизацияНедели 13-16Оптимизация, обучение

План отката:

  • Windows Server оставался включённым 30 дней после каждой фазы — не выключали, не демонтировали
  • DNS-откат: меняем DNS-серверы обратно, всё
  • Файловый сервер: возвращаем UNC-пути на Windows
  • Почта: обратная смена MX + imapsync в обратную сторону
#!/bin/bash
# rollback_dns.sh
sed -i 's/option domain-name-servers 192.168.1.10/option domain-name-servers 192.168.1.5/' \
  /etc/dhcp/dhcpd.conf

systemctl restart isc-dhcp-server

echo "DNS откачен на Windows (192.168.1.5)"
echo "Клиенты получат новый DNS при обновлении DHCP-аренды"

Обучение команды и документирование

Честно говоря, без нормальной подготовки IT-специалиста типографии вся эта инфраструктура превратилась бы в чёрный ящик уже через месяц после нашего ухода.

На документацию и обучение ушла целая неделя. Клиенты часто хотят сэкономить именно на этом этапе — и потом звонят нам каждые два дня. Здесь сэкономить не дали. Результат: через два месяца администратор типографии самостоятельно закрывал 95% задач, не трогая нас вообще.

План обучения и runbook

Обучение шло по конкретному плану, без импровизации:

  • Базовые команды Linux — навигация, файлы, пакеты, systemd (2 дня)
  • Сетевые утилиты — ip, ss, dig, nmap (1 день)
  • Samba-администрирование — smbstatus, pdbedit, testparm (0.5 дня)
  • FreeIPA — пользователи, группы, политики (1 день)
  • Zabbix — хосты, триггеры, оповещения (1 день)

Плюс написали runbook для аварийных ситуаций — что делать, если упало, и в каком порядке:

# Runbook: FreeIPA не отвечает

# 1. Проверка статуса
sudo systemctl status ipa
sudo ipactl status

# 2. Перезапуск
sudo ipactl restart

# 3. Логи
sudo journalctl -u dirsrv@COMPANY-LOCAL.service --since "1 hour ago"
sudo journalctl -u krb5kdc.service --since "1 hour ago"

# 4. Сертификаты
sudo ipa-cert-check

# 5. Восстановление из бэкапа
sudo ipa-restore /var/lib/ipa/backup/BACKUP_NAME

# 6. Контакты:
# - Главный администратор: +7 (XXX) XXX-XX-XX
# - IT-аутсорсинг: support@itfresh.ru

Результаты внедрения

От аудита до полной стабилизации — 4 месяца. Вот что получилось в цифрах:

  • Экономия на лицензиях — 380 000+ руб. ежегодно (Windows Server CAL + Exchange CAL)
  • Окупаемость проекта — 10 месяцев с учётом стоимости наших услуг
  • Стабильность — uptime вырос с 99.2% до 99.8% за первые 3 месяца
  • Безопасность — ноль инцидентов с шифровальщиками после миграции (до этого — два за год)
  • Производительность файлового сервера — сотрудники сами говорят, что стало быстрее
  • Полная совместимость — Windows-рабочие станции работают с Samba AD без единой жалобы
  • 1С:Предприятие — работает через веб-клиент, пользователи разницы не заметили
  • 60 почтовых ящиков — перенесены без потери писем, SPF/DKIM/DMARC настроены
  • Мониторинг — полная видимость через Zabbix, оповещения летят прямо в Telegram
  • Документация — runbook для всех аварийных сценариев, администратор обучен и работает самостоятельно

Самый неожиданный результат — файловый сервер реально ускорился. Сотрудники типографии годами жили с «задумчивым» Windows-сервером, который подвисал при открытии тяжёлых макетов. После миграции начали говорить, что «что-то изменилось». Замерили — скорость последовательного чтения выросла на 25–30% на том же железе. Samba на Linux просто эффективнее использует дисковый кэш, и это заметно без всяких бенчмарков.

По безопасности — за 6 месяцев после миграции ни одного инцидента с вредоносным ПО. Раньше администратор тратил до 4 часов в неделю на обновления Windows и разборки с антивирусными ложными срабатываниями. Теперь unattended-upgrades делает это тихо, ночью, без участия человека.

Администратор типографии поначалу смотрел на Linux с нескрываемым скептицизмом — это мягко говоря. Но уже через месяц сам признал: командная строка стала главным рабочим инструментом, и «возвращаться на Windows не хотелось бы». Мы оставили контакты для экстренных консультаций и раз в квартал проводим аудит инфраструктуры по договору поддержки.

Часто задаваемые вопросы

Да, именно так и делаем на практике. Сначала DNS/DHCP — это фундамент, без него никуда. Затем файловый сервер, потом каталог. FreeIPA умеет выстраивать trust с Active Directory, так что оба домена спокойно работают параллельно в переходный период. Почту переносите самой последней — там больше всего болевых точек.

У сервера 1С есть нативная сборка под Linux — никаких костылей. Клиенты работают через веб-клиент в браузере, и переучивать людей практически не приходится. Если у вас файловая база — достаточно Samba, ничего сверхъестественного.

Samba совместима с Windows полностью, и это не маркетинг — проверено годами. Samba AD DC позволяет Windows-машинам входить в домен как ни в чём не бывало. Принтеры подключаются через CUPS + Samba штатными средствами. Пользователи, честно говоря, разницы не замечают вообще.

Для компании на 50-60 человек основная статья расходов — работа специалиста: 160-320 часов в зависимости от сложности инфраструктуры. При аутсорсинге это 200 000-500 000 руб. Окупается за 1-2 года только за счёт экономии на лицензиях — и это консервативная оценка.

Бывает, что полный отказ от Windows нереалистичен — специфический софт, legacy-система, «так исторически сложилось». В таких случаях работает гибридная схема: инфраструктура на Linux, а для Windows-приложений — выделенный Windows Server или виртуалка через KVM. Терминальный доступ к ней организуем через Apache Guacamole прямо из браузера.

Нужна помощь с настройкой?

Специалисты АйТи Фреш занимаются такими миграциями больше 15 лет — и типографии, и производства, и офисы под сотню рабочих мест. Обслуживание от 15 000 ₽/мес, поможем с внедрением и настройкой под вашу конкретную ситуацию.

📞 Связаться с нами
#миграция windows linux#замена windows server#freeipa active directory#linux файловый сервер#миграция AD на linux#samba контроллер домена#linux dhcp dns#замена group policy