1. 1С Сервер: теорія і планування
2. Відмовостійкість 1С Сервера
3. Віртуалізація 1С Сервера
4. ліцензування 1С
5. Ліцензування 1С Сервера
6. Ліцензування 1С Клієнтів
7. Ліцензування: Best Practice
8. Для віртуалізованого 1С Сервера тільки апаратна ліцензія
9. Клієнтські ліцензії 1С тільки апаратні ключі
10. Ліцензування конфігурацій: СЛК, Рарус и т.д.
11. Установка 1С Сервера та інфраструктури

Тепер бухгалтерія мене обожнює:

• планування установки 1С Сервера і огляд його відмовостійкості, деталі, які необхідно знати, використовуючи віртуалізацію 1С;
• окрема глава по HASP-ключам 1С Сервера і клієнтів, програмним ліцензіями;
• умовна відмовостійкість СЛК (сервер ліцензування конфігурацій) і HASP-сервера;
• установка 1С і всієї причетної до 1С інфраструктури
• автоматична установка клієнтів 1С Підприємство на робочих станціях через групові політики;
• автоматичне прописування списків баз даних (загальний лист баз, який можна пізніше зручно редагувати в одному місці);
• прискорюємо мережу: настройка nethasp.ini на клієнтських станціях;
• працюємо з 1С та перенаправлення папками користувачів (Folder Redirection) і переміщуються профілем (Roaming User Profile).

1С Сервер: теорія і планування

1С Підприємство складається з двох частин: клієнтська частина і серверна частина. Клієнтська частина вміє самостійно працювати без сервера (в режимі «клієнт-файловий варіант», де файли бази даних зберігаються на локальному диску комп'ютера або на кулі файлового сервера), проте якщо з базою одночасно працюють кілька людей, швидкість роботи дуже сильно знижується з кожним новим користувачем. Прошу зауважити, важливо не загальна кількість користувачів, що використовують ту чи іншу базу 1С, а кількість працюючих колег з однієї і тієї ж базою в один час.

Серверна частина 1С потрібна тільки тоді, коли в компанії виникає ситуація, де з однією базою працюють більше однієї людини. У цьому випадку кожен новий відвідувач бази буде знижувати швидкість її роботи незначно, і як раз для цього і придумувався 1С Сервер. Серверна частина працює з сервером з Windows або Linux, але на Лінукс у мене є підозра на шаманство з бубном щодо налаштування доменної авторизації при вході до інформаційних баз (це тільки підозри, даремно не провів тести свого часу в своїй тестовій системі). А ця фіча дуже зручна і затребуваність. Крім того, є дві версії 1С Сервера: 32-бітна (прекрасно працює) і 64-бітна (в 2 рази дорожче і на моїй практиці ніде ще плюси 64-бітової версії не проявилися). 32-бітна версія також працює в 64-розрядної ОС. 1С сервер прекрасно працює у віртуальному середовищі з застереженнями по системі ліцензування (про це нижче). Варто відзначити факт, що в операційній системі Windows система 1С Сервера працює стабільніше (з багатьох причин, аж до того, яким чином і на яких системах тестуються конфігурації 1С).

Серверна частина працює з СУБД на основі:

• MS SQL. Версія не важлива, підтримуються 2000 - 2012 версії, реліз підійде навіть безкоштовний Express (він жорстко обмежений розміром бази даних, в MS SQL 2012 Express це не більше 10 Гб на базу, що реально перекреслює використання великих конфігурацій). Дуже сильно рекомендується використовувати саме цю СУБД через відомої: розробники конфігурацій для 1С заточують свої рішення для цієї СУБД. Багато зламали списи, обговорюючи неоптимальні запити в базу даних, при програмуванні конфігурацій. Однак MS SQL працює з цими конфігураціями на порядок краще безкоштовної СУБД PostgreSQL (порядок - це в 10 разів), і не тому що PostgreSQL гірше.
• PostgreSQL. Безкоштовна СУБД рівня Enterprise, яка вміє кластерізованний і працювати з 1С Сервером (необхідно ставити версію, пропатченних 1С-програмістами, її можна знайти на http://users.v8.1c.ru ). Postgre SQL працює з 1С повільно, особливо PostgreSQL на Windows. На практиці, використовував віртуальну машину з Лінукс і Постгрі, на хорошому двупроцессорном сервері з SAS дисками 8 штук і рейдом 10: рішення отримало рекордно можливу продуктивність (за відгуками форумчан), здатну обслуговувати до 40 конкурентних користувачів в 80 базах 1С Сервера (версії 8.2 і трохи 8.1). Однак 1С «не літав», особливо в звітні періоди бухгалтерії. Особливо, коли postgresql в тлі починав перевіряти свої бази після відключення живлення сервера. В результаті у мене на одну найбільшу базу припадало 25 конкурентних користувачів (по офісу їх набирається 100, але одночасно в піку працювало до 25 осіб), і Postgre справлявся із завданням. Але це абсолютний стелю, мені здається. Вичавлювати швидкість роботи з PostgreSQL і 1C Сервером треба більше на стороні оптимізації коду конфігурацій, якщо апгрейда серверного обладнання (був досвід в цьому чітко переконатися), але це вже зовсім інша пісня зі зльотом з технічної підтримки конфігурації, власною командою 1С-програмістів в штаті і зовсім іншого бюджету, з лишком перевалює за вартість MS SQL. Ну і останнє: відмовостійкість PostgreSQL, пропатченний командою 1С (а необхідно використовувати тільки Патчений Postgre), працює тільки на СУБД, встановленої на Лінукс;
• IBM DB2. Є безкоштовні версії цієї СУБД (IBM DB2 Express-C), обмежені виконанням процесів СУБД 2 процесорними ядрами і 4 Гб ОЗУ. Express-C не піддається кластеризації, і по суті застосування рішення IBM для 1С-Сервера мені зовсім не цікаво. Однак для мене це незнайомий продукт, нічого про нього сказати не можу, тим більше, як це все працює з 1С Сервером;
• Oracle Database. Нові релізи 1С Сервера стали підтримувати цю дуже дорогу СУБД. Насправді я здивований мінімальним відсотком впроваджень 1С Сервера з Oracle Database. 1С Платформа як така - рішення доступне за коштами і з усіма властивими йому мінусами (в тому числі низької продуктивності). Oracle DB - рішення дуже дороге для компаній-гігантів, де, насправді, вже повинні бути власні розробки власних систем власним відділом програмування департаменту ІТ. Я думаю, всі зрозуміли, на що я натякаю. Реалізацію 1С Сервера з Оракл я не практикував, нічого більше про цю реалізації сказати не можу.

Відмовостійкість 1С Сервера

Відмовостійкість визначається найслабшою ланкою ланцюжка. Тому перерахуємо їх все і будемо розмовляти про кожному компоненті окремо:

1. 1С Сервер. Служба, яка працює в операційній системі, яка бере дані від клієнтів 1С і працює з базою даних на СУБД. Кластеризуються установкою другого 1С Сервера. В результаті має бути дві і більше Ноди 1С сервера. Точно також потрібно дві ліцензії на 1С Сервер (32-бітна або 64-бітна). Є ще одна реалізація відмовостійкості: робота 1С Сервера в віртуальному середовищі на відмовостійких Гіпервізор, що дає нам право використовувати тільки 1 ліцензію 1С Сервера і мати достатню надійність;
2. СУБД зберігає дані баз, і відповідно, також повинна бути високодоступних. А це кластер з MS SQL або PostgreSQL (IBM DB2 і Oracle DB я не розглядати через відсутність практичного досвіду реалізації 1С з ними). У цій статті не планується описувати питання кластеризації SQL, проте матеріал про кластері MS SQL 2012 і PostgreSQL 9.1-9.2 я планую винести в окрему статтю пізніше. Точно також як і 1С Сервер, СУБД можна зробити відмовостійкої, помістивши її в віртуальне середовище на відмовостійких Гіпервізор.
3. Ліцензування. Погано піддається відмовостійкості. Виділив питання ліцензування в окрему графу нижче.

Віртуалізація 1С Сервера

1С Сервер прекрасно працює у віртуальному середовищі на будь-якому гіпервізора. Є деякі моменти щодо ліцензування 1С, про які варто пам'ятати, плануючи 1С Сервер у віртуальній машині. Всі ці моменти описані в окремому розділі нижче.

ліцензування 1С

Ліцензування ділиться на ліцензування 1С Сервера (серверної частини), 1С Клієнтів (клієнтські ліцензії), і конфігурацій 1С (деякі конфігурації).

Ліцензування 1С Сервера

У 1С Сервера (серверні ліцензії) бувають програмні і апаратні ліцензії. Можна вибрати тип ліцензії при її покупці: або листок з серійним номером і кодом активації, або USB-пристрій (HASP) з ліцензією всередині.

• Програмні ліцензії працюють і активуються, але після цього виртуалку не можна перемістити на інший хост. У разі, коли віртуальна машина мігрує на іншу ноду віртуального кластера, служба 1С Сервера не запуститься і буде лаятися на ліцензію. Все це говорить про те, що програмна ліцензія не підходить для відмовостійкості на рівні віртуальної машини 1с сервера. Чому все так? Тому що програмна ліцензія, при активації запам'ятовує модель CPU, ID материнської плати, розмір жорсткого диска (можна змінити в бік збільшення), номер ОС і дату її установки і цілу серію інших параметрів, половина з яких зміниться, якщо виртуалка смігрірует на інший комп'ютер.
• Апаратні ліцензії. У 2013 році стали коштувати дорожче програмних з незрозумілих мені причин. Якийсь чорний маркетинг, мені здається. Апаратні ліцензії - це USB-пристрої. Для 1С Сервера USB-ключ з ліцензією необхідно встановити локально на 1С Сервер. Якщо сервер 1С НЕ віртуалізувати - проблем не виникає. Однак в разі віртуальної машини, необхідно «прокинути» ключ в виртуалку. Це вміє робити ESX (i) з коробки. Виртуалка отримує проброшенний USB-ключ і прекрасно працює. АЛЕ! У момент міграції віртуальної машини на інший комп'ютер, виртуалка втратить USB-ключ, встромлений в перший ESX (i). 1С Сервер не запуститься, ніж перекреслює всі смаколики віртуального кластера. Ок, є ще спеціальні девайси і ПО, яке може прокинути будь-який USB через мережу в будь-який комп'ютер або виртуалку. На практиці дуже добре себе зарекомендував софт USB Redirector за 80 баксів на 2 USB-пристрої, який прокинув ліцензію в 1С Сервер, і виртуалка останнього може «плавати» по Нодаме Hyper-V кластера або ESX (i) як їй заманеться. Але знову виникає АЛЕ! В цьому випадку USB Redirector є точкою відмови, слабкою ланкою. Як організувати його роботу на догоду вимог до відмовостійкості? Давайте поговоримо докладніше
• USB Redirector: б'ем на смерть з обмеженнями питань ліцензування 1С Сервера. USB Redirector (або його аналог) - це спеціальний софт, який ставиться «серверної» частиною на комп'ютер з USB-портами (це може бути старий комп'ютер з Windows з курній комори), і «клієнтської» - на виртуалку з 1С Сервером. Налаштовуємо софт, перевіряємо автозапуск служби USB Redirector-a і все працює (не забуваємо на 1С Сервер поставити драйвера захисту HASP). Тепер про відмовостійкості: щоб гарантувати, що USB-ключ з ліцензією добирається до 1С Сервера, потрібно кластеризувати «серверну» частина USB Redirector-a. Але як, якщо у нас всього один ключ з ліцензією 1С Сервера ?! Купувати другий ключ, купувати другий USB Redirector і налаштовувати на прокідиваніе другого ключа! Далеко не кожен дозволить собі купити дві ліцензії 1С Сервера, і піде на будь-які хитрощі, щоб обійти обмеження системи ліцензування 1С. І я один з них: я зібрав два однакових старих комп'ютера з Windows 7, поставив на обох USB Redirector, в обидва по-черзі повтикать USB-ключі і налаштував кидок в віртуальний 1С Сервер. Обидва сервера у мене тепер сервера ліцензування LicenseServer01 і LicenseServer02. Тепер при падінні одного з них, система перестане працювати до тих пір, поки я не піду в серверну і не переставлю ключі з одного компа в інший (а щоб не заплутатися в портах, бо ключі треба строго встромляти в порти, на яких ти вже налаштував прокинув, я підписав і ключі, і порти). Звичайно, такий підхід настільки обмежує можливості «високої доступності», що все-таки слід хоча б розглянути варіант придбання другої ліцензії 1С Сервера. Уявімо, у нас на руках 2 ключа з ліцензіями, два USB Redirector-а, і все налаштовано і навіть працює після відмови одного з комп'ютерів ліцензування. А «нафіга попу наган, якщо він не хуліган?» А давайте тепер подивимося глобальніше: якщо у тебе куплено два ключа 1С Сервера, чи не простіше встановити зо два не віртуалізованих сервера 1С та повтикать в них локальні USB-ключі, зібрати з них кластер інструментами самого 1С і буде тобі щастє? Ось як нас обмежує 1С зі своєю не найвдалішою системою ліцензування!

Ліцензування 1С Клієнтів

1С Клієнти - це програми 1С, які запускаються на робочих станціях кінцевих користувачів. Клієнтські програми 1С теж необхідно ліцензувати, і тут теж бувають як програмні, так і апаратні ліцензії. Можна вибрати тип ліцензії при її покупці: або листок з серійним номером і кодом активації, або USB-пристрій (HASP) з ліцензіями всередині.

• Програмні ліцензії можуть бути активовані в двох місцях: на 1С Сервері (тоді сервер буде видавати вільні клієнтські ліцензії на кожну сесію з сервером), або на комп'ютері користувача (одна ліцензія на будь-яку кількість сесій з 1С Сервером + права запуску файлової бази з кулі файлового сервера або з локального жорсткого диска). У разі, коли комп'ютер у користувача змінюється, програмна ліцензія злітає: при її активації запам'ятовується CPU, ID материнської плати, розмір жорсткого диска (можна змінити в бік збільшення), номер ОС і дату її установки і цілу серію інших параметрів. Переактівіровать тугіше програмну ліцензію 1С клієнта можна обмежена кількість разів: в папірці з ліцензіями зазначено всього 3 коду активації, крім того, «резервні» коди активації можна отримати за запитом в техпідтримку 1С, але ви опинитеся на олівці.
• На відміну від серверної ліцензії, апаратний HASP-ключ може містити різну кількість ліцензій (5 клієнтських ліцензій, 10, 20 і т.д.) і може бути встановлений на будь-який комп'ютер в локальній мережі. Цей комп'ютер буде «роздавати» ліцензії 1С клієнтам за допомогою софта HASP Licence Manager. Таким чином, на робочих станціях користувачів 1С ні USB-ключ, ні драйвера ключа захисту встановлювати не потрібно. Будь-який комп'ютер в мережі може отримати ліцензію від HASP Licence Manager. Це зручно: 1С Підприємство встановлено на всіх комп'ютерах організації, при цьому не порушуються умови ліцензування 1С. Але одночасно з 1С не повинно працювати більш n-числа комп'ютерів в локальній мережі, де n-це кількість клієнтських ліцензій HASP-ключа. При цьому кожен комп'ютер, який отримує ліцензію, має право запускати необмежену кількість баз. Для сервера HASP License Manager логічно використовувати вже наявний у мене LicenseServer01 і LicenseServer02, які використовуються для перекидання серверного USB-ключа 1С в відповідну виртуалку. У мене один HASP-ключ, встановлений в LicenseServer01. Коли користувачів 1С побільшає, я куплю додатковий HASP-ключ і вставлю його в LicenseServer02. 1С Клієнти зрозуміють, що в мережі два сервера ліцензій і будуть брати ліцензію з того сервера, де є вільна ліцензія. Якщо один з серверів вийде з ладу, другий продовжить роздавати ліцензії згідно із законом «хто перший - того і тапки».

Ліцензування: Best Practice

Набравшись досвіду в питаннях ліцензування 1С, розумієш, наскільки практика використання того чи іншого виду ліцензування 1С відрізняється від незрозумілої теоретичної викладки в документації 1С. Тому я оформлю короткий список кращого практичного застосування і вкажу його плюси.

Для віртуалізованого 1С Сервера тільки апаратна ліцензія

Причини: програмна ліцензія не дозволить запустити 1С Сервер на іншому гіпервізора без реактивації. Кожна міграція вимагає реактивації, а з огляду на її кількісної обмеженості, змушує використовувати апаратний USB-ключ Переваги: ​​простота перенесення ліцензії, потрібно тільки підключити USB-ключ до сервера. Недоліки: доводиться «прокидати» USB-ключ на віртуальну машину, що задіє додатковий комп'ютер або спеціальне обладнання. Недолік нівелюється тим, що на цьому ж комп'ютері можна розгорнути HASP License Manager для клієнтських ліцензій

Клієнтські ліцензії 1С тільки апаратні ключі

Причини: програмні ліцензії треба переактівіровать при зміні комп'ютера, що незручно. Програмні ліцензії, встановлені на сервер, витрачаються за схемою «ліцензія-на-відкриту-базу», коли як інші способи - «ліцензія-на-комп'ютер-де-відкривається-необмежену-кількість-баз». На відміну від апаратної ліцензії, кількість програмних ліцензій обмежує кількість комп'ютерів, на які можна встановити і активувати для запуску 1С Підприємство. Переваги: ​​зручність роботи - кожен комп'ютер офісу може працювати з 1С, зайнявши конкурентну ліцензію у HASP License Manager. Немає необхідності в адмініструванні ліцензій, їх перенесення і реактивації. Недоліки: потрібен комп'ютер - сервер для запуску HASP License Manager. Нівелюється тим, що на цьому ж комп'ютері можна розгорнути кидок USB-ключа для 1С Сервера.

Ліцензування конфігурацій: СЛК, Рарус и т.д.

Існують деякі конфігурації, Які окремо ліцензуються. Для таких конфігурацій існують «Катрановскіе» USB-ключі и дуже Рідко Програмні Ліцензії. КОЖЕН вендор, что віпускає свою продукцію, має право скористати СЛК (система Ліцензування конфігурацій) - Спеціальний софт, написаний 1С-ом, Який Контролює Кількість Користувачів, что Працюють з Певного конфігурацією. Однако деякі Виробники конфігурацій воліють використовуват свой софт контролю Ліцензування, например, Рарус. Всі ЦІ програми ставлять на будь-який комп'ютер в локальній мережі. Адреси цього комп'ютера вказується при Першому запуску конфігурації на робочому місці користувача 1С (Вже Всередині Відкритої інформаційної бази), и в момент запуску бази, 1С Клієнт звертається за інформацією про Ліцензування до цього комп'ютера. Подібний софт, я, звичайно ж поставив на наявні у мене LicenseServer01 і LicenseServer02, які вже використовуються для перекидання серверної ліцензії і роздачі клієнтських ліцензій HASP License Manager. Зараз у мене тільки в одному LicenseServer01 встромлені ключі конфігурацій. Ні про яку відмовостійкості серверів ліцензування мови бути не може. Навіть якщо придбати другий комплект ліцензій конфігурацій, який можна буде встановити в LicenseServer02, налаштувати 1С Клієнт для використання ДВОХ LicenseServer неможливо спочатку! Використовуючи DNS Round-Robin A-запис, ми отримаємо результат, коли ліцензування працює аби-як: то не може підключитися до сервера ліцензування, то підключається до сервера, де ліцензії закінчилися, то справно отримує ліцензії ... наколінні рішення - тримати за пазухою вже налаштований на ключі конфігурацій резервний сервер ліцензування, причому вимкнений, з тим же ip-адресою, що і основний СЛК. Щоб в аварійний момент прийти руками перетикнуть USB-ключі і включити цей cold backup server. Чи не айс, товариші! Навіть якщо придбати ліцензії рівно в два рази більше потрібного кількості і поділити їх на два СЛК-сервера, це не гарантує успішної видачі ліцензій в разі виходу з ладу одного з СЛК до тих пір, поки обидва СЛК не працюватимуть на Windows Server з Failover Cluster , де певний ip-адреса в якості ресурсу ролі кластера буде мігрувати від однієї ноди до іншої, при цьому запускаючи службу СЛК тільки там, де ip-адреса призначена. Але це ж зовсім інші гроші ...

Установка 1С Сервера та інфраструктури

Приступимо до встановлення 1С Сервера. На зображенні видно ілюстрація кроків розгортання системи. У даній статті я не буду розглядати тонкощі розгортання гипервизора і його кластера. Зазначу лише факт, що 1С Сервер прекрасно працює у віртуальному середовищі в будь-якому гіпервізора, кластерізованний він чи ні.

1. Отже, почнемо з інсталяції та оновлення ОС (я вибрав Windows 2003 R2 x64 через наявної ліцензії на нього і більше 4 Гб оперативної пам'яті). Ніяких особливих вимог до даного пункту немає. 32-бітний 1С Сервер працює на 64-разярядной ОС.
2. Введення сервера в домен. Необхідно для роботи прозорою авторизації (доменна авторизація при запуску 1С клієнта на доменних комп'ютерах - автоматичний логон в інформаційну базу 1С).
3. Установка 1С Платформи для Windows: скачати, розпакувати і запустити setup.exe. При установці вибрати такі компоненти: «Сервер 1С: Підприємства»; «Інтерфейси на різних мовах - Русский» (за бажанням). Інші компоненти на сервері зовсім не потрібні. У наступному вікні запитає про обліковий запис, з під якої запускати сервер 1С. Слід вибрати будь-яку існуючу локальну учетку комп'ютера (інсталятор не вміє вказувати доменну учетку, і це ми зробимо при першій же можливості вручну). Далі - встановити драйвер захисту (поставили її галку). Інсталятор почне роботу, але в кінці його виконання може виникнути помилка запуску служби 1С Сервера. Це не страшно. Йдемо в оснащення служб, шукаємо «Агент 1С Сервера», у властивостях вказуємо обліковий запис домена, з під якої хочемо запускати сервіс (рекомендую створити окрему учетку без будь-яких прав доступу), і параметри відновлення служби (перезапуск при збої). Ще не запускаємо службу. Спочатку треба зайти в директорію C: \ Program Files \ 1Cv82 і дати в ній повні права для нашої облікового запису служби. Крім того, необхідно зайти в консоль «Локальна політика безпеки» - Параметри безпеки - Локальні політики - Призначення прав користувача. У графи «Вхід в якості пакетного завдання» і «Вхід в якості служби» додати обліковий запис служби 1С Сервера. Після цього службу можна запустити.
4. Відкрити консоль управління 1С Сервером: Пуск - Всі програми - 1С Підприємство - Додатково - Адміністрування серверів 1С Підприємства. Додати сервер 1С по імені комп'ютера, задати паролі Адміністратора на рівні сервера і на рівні кластера. У властивостях кластера вказати параметри як показано на скріншоті.
   
5. Додати новий робочий процес:
   
6. Після цього - секрет фірми: загасити службу Агента 1С Підприємство, і отредактровать файл: C: \ Program Files (x86) \ 1cv82 \ srvinfo \ srvribrg.lst таким чином, щоб змінити NETBIOS ім'я сервера на DNS-ім'я служби 1С Сервера (перед цим його треба придумати і зареєструвати у внутрішньому DNS-сервері в якості A-записи). У мене це ім'я фігурує як 1CEntServer01.itisok.ru.

Приклад мого файлу srvribrg.lst:

{1,

{4r483757 - 81b0 - 58q2 - 8gkt - 0e4956bd9482, "1С Кластер Сервера", 1 541, "1CEntServer01.itisok.ru", 0, 0, 86400, 86400, 4194304, 300}

},

{1,

{ "Administrator", "", "", "there_is_hash", "", 1}

}, 0, 1}

Далі за таким же образом і подобою відредагувати файл C: \ Program Files (x86) \ 1cv82 \ srvinfo \ reg_1541 \ 1CV8Reg.lst, змінивши імена на більш підходящі. У цьому файлі крім налаштувань служб 1С Сервера, зберігаються дані про інформаційні базах. Кожен запис інформаційної бази має свій sID, який міняти не можна (виникнуть помилки на стороні клієнта). Я наведу приклад свого файлу на свіжовстановленому 1С Сервері без інформаційних баз.

Приклад мого файлу 1CV8Reg.lst:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

] {0,

{4r483757 - 81b0 - 58q2 - 8gkt - 0e4956bd9482, "1С Кластер Сервера", 1 541, "1CEntServer01.itisok.ru", 0, 0, 86400, 86400, 4194304, 300},

{0},

{2,

{Djfh5732 - 3445 - 9936 - vdh7 - djfh5739vhdd, "1CEntServer01.itisok.ru", 1, 0 1000},

{Dkfjg735 - 2846 - 3846 - sdkj - dfh87e90w57e, "1CEntServer01.itisok.ru", 1, 0 1000}

},

{1,

{ "Administrator", "", "", "there_is_hash", "", 1}

},

{1,

{384756s3 - 3467 - 2895 - 8487 - sdgdf5d45485, "1С Сервер 01", 1540, "1CEntServer01.itisok.ru", 1,

{1,

{1560 1591}

}, "", "There_is_hash"}

},

{0},

{0},

{1,

{ "1CEntServer01.itisok.ru", 1541}

}

Редагування файлів необхідно для зміни імен кластерів і імен робочих процесів, що неможливо зробити через консоль. Тепер можна запустити служби та перевірити всі зміни, запустивши консоль управління 1С Сервера. 1С Сервер встановлений і налаштований. У нього можна прописувати або створювати інформаційні бази через ту ж консоль 1С Сервера.

Чекайте завершення написання статті ... Скоро будуть поповнення, а поки трохи фана: