конфигурация сети - посоветуйте - Сети

Kravetz · 18.07.2006, 00:56

Ребята подскажите, пожалуйста.
Поставлена задача - реорганизовать сеть нашего предприятия. А именно.
У нас четыре юр.лица и руководство хотело бы, чтобы каждое из них имело свою сеть. Ну да ладно - то, что хочет руководство это пожелания, но они, само собой, не специалисты в этом вопросе - решать доверено это дело мне. Так вот.
Посоветуйте каким образом лучше структурировать сеть. Дано: в каждом этом сегменте будет свой сервер и по 8 рабочих станций (для начала, дальше они будут расти). Основная задача сервера - базы 1С, к ним подключаются в терминальном режиме. Значится какие есть варианты.
Вариант первый (типа: все гениальное просто)
Сделать четыре рабочих группы. Адресация у всех одинаковая, типа: 192.168.0.1/254. Вот, в сущности и все. Все, вроде как, должно работать и, на мой взгляд, никаких подводных камней в себе эта структура не несет. Разве что только - не хотелось бы иметь дело с рабочими группами - домены, все же, лучше. Впрочем - если есть аргументы в обратную сторону с удовольствием к ним прислушаюсь.
Вариант второй (сложнее, но интереснее - склоняюсь к нему)
Сделать четыре доменных дерева в одном лесу. И тут уже возникают вопросы.
1. Будет ли все работать хорошо, если в этой структуре будет один DHCP-сервер? Рабочие станции с других доменов примут динамическую адресацию? Никаких подвохов не будет? А если сделать так: разбиваем диапазон 192.168.0.1/254 на 5 частей (приблизительно по 50 IP) и на каждом контроллере домена делаем свой DHCP который выдает адреса только со своего диапазона? Вроде как отказоустойчивость должна быть отличной? Никаких же конфликтов в этом случае не предвидится? И опять же: была сказана мысль, типа, чтобы все работало так: взяли организацию и отправили ее со своей техникой в далекие края - в этом случае ведь этот домен вообще ничего не связывает с другими, он совершенно автономен и функционален? Я прав? Или есть подводные камни?
2. Насколько сложно настроить, в этой ситуации, доверительные отношения между доменами? Или это просто? Или, опять же - есть подводные камни? Чтобы соответствующие пользователи имели доступ к необходимым ресурсам в других доменах - ведь ничего сложного в этом нет?
3. Как уже говорилось - основная задача серверов - базы данных 1С. Люди работают в терминальном режиме. Вариант когда контроллер домена стоит на отдельном сервере и помимо этого в этом домене есть сервер баз данных - этот вариант пока нецелесообразен, дороговато пока. Отсюда вопрос: контроллер домена работает еще и как сервер баз данных - это нормально, ничего страшного не случится? Что можете сказать по этому поводу?
4. Относительно настройки DNS - на каждом контроллере домена установить планирую DNS. Никаких подвохов в этом не вижу. Что скажете?
Ух!
Вот такие вопросы, дальше еще может появятся.
Уважаемые - будьте добры, посоветуйте - с чем могу сложным столкнутся, что не учел, как можно сделать лучше.

gluon · 18.07.2006, 11:42

C DHCP проблем точно не будет.
“Сделать четыре доменных дерева в одном лесу” – доверительные отношения установятся автоматом, будут транзитивными и двусторонними.
С DNS тоже проблем никаких, делать интегрированные, если не ошибаюсь, областью "репликации DNS" можно сделать все контроллеры леса со службой DNS.

Только вот ради каждых 8 рабочих станций держать контроллер домена, ещё и с учётом того, что не рекомендуется службы AD и TS держать на одном сервере...

А почему просто не сделать один домен, а остальное, если уж нужно, рулить организационными единицами?

KomatoZo · 18.07.2006, 12:24

Цитата:

Kravetz:
Будет ли все работать хорошо, если в этой структуре будет один DHCP-сервер

В принципе да, но только если руководить ВСЕЙ структурой будет одна команда. Подвохи могут быть с динамической регистрацией рабочих станций в DNS, но, по идее, это можно обойти.

Цитата:

Kravetz:
диапазон 192.168.0.1/254 на 5 частей

Лучше взять им разные диапазоны - на будущее. Тебе не жалко, а работы потом будет меньше. Да и чисто психологически удобнее их по разным подсетям раскидать.

Цитата:

Kravetz:
он совершенно автономен и функционален? Я прав?

Не прав. Мастер схемы и мастер контекста именования один на весь лес. Так что если ты один домен (не корневой) отправишь в далекое автономное плавание, то рано или поздно в нем возникнут проблемы. Например, exchange зачастую поставить или обновить серьезно не сможешь. Или добавить поддомен в это дерево.

Цитата:

Kravetz:
доверительные отношения между доменами

Все сказано товарищем gluon

Цитата:

Kravetz:
контроллер домена работает еще и как сервер баз данных - это нормально

Ну вообще, конечно, рекомендуется разводить такие роли. Но, в принципе, ничего страшного в данном конкретном случае не предвидится, кажется. По этому поводу лучше обратиться к докам на technet по поводу SQL.

Цитата:

Kravetz:
Относительно настройки DNS

Да. Правильно. На каждом DC DNS сервер. С интегрированными зонами.

Теперь дальше - почему действительно не сделать отдельные OU для каждого юр. лица. Слишком уж громоздко получается все на несчастных 30 юзеров 4 домена. То есть, если следовать рекомендациям MS - минимум 8 DC. В принципе вариант имеет право жить, если есть бизнес-требования, заставляющие сделать именно так, но очень уж затратно получится. И с точки зрения единовременных затрат и с точки зрения администрирования.

UPD: Кстати, очень толково вопросы задаете, товарищ =)
Приятно отвечать. Всем бы так.

Kravetz · 18.07.2006, 13:18

Цитата:

Сообщение от gluon

А почему просто не сделать один домен, а остальное, если уж нужно, рулить организационными единицами?

Смущает именно это пожелание - чтобы все эти подразделения были, типа, автономными. Вроде того - одно юр.лицо снялось и уехало в дальние края. Думаю, что без контроллера домена они далеко не уедут? Или как?

KomatoZo · 18.07.2006, 13:23

Kravetz
Если их немного, то уедут. Но опять таки при наличии канала до центрального оффиса. Если каналов нет, то в любом случае, уехать они могут только при наличии на каждую контору своего леса. ИМХО.

Kravetz · 18.07.2006, 13:26

Цитата:

Сообщение от KomatoZo

Лучше взять им разные диапазоны - на будущее. Тебе не жалко, а работы потом будет меньше. Да и чисто психологически удобнее их по разным подсетям раскидать.

Вот с этим раньше дело не имел - это если честно. А каким образом будет связь между подсетями? Что необходимо? Типа - маршрутизацию поднимать? А где и как? Добавлять дополнительные сетевые интерфейсы на серверах? Или роутер покупать и настраивать? Вот только на знаю толком как его настраивать. Компы из нашей сети хотят в интернет через роутер - не будет проблем с настройкой если появятся четыре подсети и все они пойдут в этот самый роутер? Я просто туго себе это представляю - подскажите, пожалуйста.

И опять по поводу одного домена и организационных групп - у меня именно такая мысль поначалу и появилась - но смутило именно это пожелание - разделить все юридические лица.
Посоветуйте - а как бы Вы поступили в этом случае?

Вам спасибо за ответы! Реальное спасибо - ибо я понимаю, что не каждому захочется терять свое время отвечая на различные вопросы.

gluon · 18.07.2006, 13:53

Ну так и пускай едут с контроллером, в этом смысле ситуация с лесом или одним доменом мало чем отличаются, всё равно придётся их как то связать (через Интернет… VPN). Если же речь идёт о “полной автономии”, т.е. уехали и связи никакой, то (как уже говорил KomatoZo) решение с лесом не подойдёт, только изолированные домены (леса) и трастинг руками. А вообще при уезде 8 рабочих станций на новом месте можно сеть и с нуля сделать.

… ну да, ежели всё же лес… можно с “уезжающими” отправить “клон” первого контроллера первого домена (с нужными ролями) (двоеточие правая скобка)

Kravetz · 18.07.2006, 14:58

Ну допустим тогда такой вариант.
Значится так:
делается один домен, у него один контроллер домена с DHCP и DNS.
В этом домене создаю четыре подразделения (по количеству юр.лиц). У них у всех свои 1С базы. А если сделать так - на мой взгляд для каждого подразделения по одному серверу на 1С базы как-то жирно получается - может сделать мощный сервер и все базы разместить там - соответственно дать доступ нужным бухгалтериям только к своим базам. Можно съэкономить на покупке лишних серверов. Я нигде не ошибаюсь - я не специалист в 1С, но, насколько понимаю - каждая бухгалтерия работает со своими базами и никто друг другу не мешает? В этом случае можно было бы обойтись тремя серверами - контроллер домена и два для баз. В принципе - для такого количества рабочих станций (ведь их пока немного) хватило бы и одного хорошего сервера - ведь так?
Если начальство хочет - можно разделить доступ из одного подразделения в другое - чтобы не шастали где не нужно, а кому нужно дать разрешение шастать где хочет.
Допустим возникает ситуация когда нужно уехать юр.лицу - делаем ему сервер - дополнительный контроллер домена, копируем базы 1С - и пусть катит? Или даже, в принципе - просто копируем базы на носитель. Приходим на новое место, берем новый сервер - поднимаем домен, ставим 1С, копируем обратно базы и все будет работать? Ведь так? Я нигде не ошибаюсь?
Ух! Мне кажется, что это оптимальный вариант.
Подкажите уважаемые - что думаете по этому поводу.

Спасибо Вам за участие в моей проблеме!

KomatoZo · 18.07.2006, 15:04

Можно поднять роутер между ними. Железный или софтварный - дело вкуса, денег и желания научиться. Железный это как правило какая нибудь Cisco (минусы - придется учиться, плюсы - за такое обучение зарплата не понижается а вовсе даже наоборот=) ). Если брать какой нибудь бестолковый роутер а-ля SOHO, то лучше уж поднять отдельный сервачок-маршрутизатор.
Как я поступил бы в конкретной ситуации - сказать сложно. Это уже вопрос дизайна домена AD. Очень много разных параметров. Но MS везде твердит, что основанием для раздела на многие домены могут быть только законодательные требования и/или желание предельно изолировать управление. Ни того ни другого я не вижу. Делать отдельные леса - это вообще в случае если организации с совсем раздельным управлением. Так что лично я вижу только вариант с OU - но это опять-таки на вкус и цвет каждого. Кроме того вы там, а я здесь. Возможно я чего-то не допонимаю. Разделить все юр. лица можно на уровне разрешений и/или полномочий. Только надо заранее продумать структуры OU, сайтов, GPO, политик безопасности и разграничения доступа.
Еще совет: не пожалейте времени... Найдите и пролистайте книжку по AD. Можно хоть учебник по MS для экзамена 70-294. Очень полезное чтение как раз в вашей ситуации. А уже потом решайте.

Цитата:

Kravetz:
делаем ему сервер - дополнительный контроллер домена, копируем базы 1С - и пусть катит?

К сожалению - не совсем правильно. Я уже говорил про ограничения, связанные с наличием канала связи и репликациями. под всем остальным готов подписаться. Разве что в 1С я тоже не секу =)

gluon · 18.07.2006, 15:45

Всё верно, не понял только точного значения фразы “делаем ему сервер - дополнительный контроллер домена”, судя по следующей фразе “берем новый сервер - поднимаем домен” вроде имеется в виду всё же создание изолированного домена никак не связанного с “первоначальным”, или всё же ещё один контроллер в том же домене, отправляем его на удалённую площадку и налаживаем связь? Тогда действительно придётся слегка попариться… почитать книжки к экзаменам 70-298, 70-299, 70-350…

… по 1С (...необходимому количеству и "качеству" серверов) трудно давать рекомендации ничего не зная о исходных данных и условиях проекта (7.7 или 8.0, SQL или dbf , какие конфигурации, сколько пользователей, скольким нужно работать одновременно, что они делают и насколько интенсивно… может и TS не нужен), теоретически на одном сервере может стоять любое количество баз, и перетащить любую из них на другой сервер – не проблема

KomatoZo · 18.07.2006, 16:13

=)
Попариться действительно прийдется. Особенно, если не охота потом локти кусать. Начинать все-таки рекомендую с 294. Может быть 293, но я ее еще не читал. 298 как-то не впечатляет, оно скорее для именно проектирования системы безопасности, чем для конкретного внедрения. Скорее 299. 350 - да, если будешь через ISA все делать.
Для удаленной площадки можно поднимать отдельный домен, но я уже говорил - не вижу причины. Можно отдельное OU и, как следствие удаленности площадки, отдельный site. DC там можно не ставить, если количество юзеров меньше 50ти, но тогда нужен надежный канал. Именно надежный, а не толстый. Толщина может быть достаточно небольшой при таком количестве ресурсов. Если канал может падать - лучше поставить там DC и настроить кеширование членства в универсальных группах. Ну и т.д. В общем, даже по-хорошему завидую - самому так и не довелось поднять что-либо подобное с нуля. Обычно приходится либо в пределах одного сайта-домена крутиться, либо перекурочивать сделанное кем-то =)

Kravetz · 18.07.2006, 16:14

Да, именно имеется в виду новый домен никак не связанный с изначальным.

По поводу 1С - версия 7.7, базы dbf. Комплексная конфигурация. Все работают в терминале - удаленный рабочий стол. Всего около 28 пользователей - это максимум на текущий день. Какой должен быть сервер, чтобы это потянуть. 2*Intel Xeon 2.6 Ghz + 4 Gb ОЗУ - хватит?
И еще: хотелось бы иметь лицензионное ПО - стандартный вариант Windows 2003 Server Standart Edition + 5 клиентских лицензий. Отсюда очередной вопрос: клиентов-то больше. Но, тем не менее, будет ли работать ОС без глюков? Или ругнется на число подключений? Соответственно придется докупать еще лицензии. Либо все будет работать и так, просто превышение пользователей это нарушение лицензионного соглашения.

KomatoZo · 18.07.2006, 16:18

Цитата:

Kravetz:
Да, именно имеется в виду новый домен никак не связанный с изначальным

Если не связанный, то это отдельный лес. Со всеми вытекающими.

gluon · 18.07.2006, 17:11

я думаю, с запасом, если, конечно, все не бросятся годовые отчёты строить или что-нибудь в этом роде, в “пиковые” моменты косяки возможны (и дело не столько в железе сколько в архитектуре "1С 7.7 dbf"), но и здесь ситуация облегчается тем, что, насколько я понимаю, все сидят не на одной базе, как уже говорил, не рекомендую использовать этот же сервер в качестве контроллера домена

рад бы что-нибудь сказать про лицензирование, но “не приходилось сталкиваться с подобными проблемами”

KalaSh · 18.07.2006, 17:29

Цитата:

Kravetz:
И еще: хотелось бы иметь лицензионное ПО - стандартный вариант Windows 2003 Server Standart Edition + 5 клиентских лицензий. Отсюда очередной вопрос: клиентов-то больше. Но, тем не менее, будет ли работать ОС без глюков? Или ругнется на число подключений? Соответственно придется докупать еще лицензии. Либо все будет работать и так, просто превышение пользователей это нарушение лицензионного соглашения.

2003-й в домен не будет пускать, CALы придётся докупать для каждой станции, стоит ~ 60 у.е. для одной рабочей единицы.

18.07.2006, 00:56	# 1
Kravetz Newbie Регистрация: 11.04.2006 Сообщения: 26	конфигурация сети - посоветуйте Ребята подскажите, пожалуйста. Поставлена задача - реорганизовать сеть нашего предприятия. А именно. У нас четыре юр.лица и руководство хотело бы, чтобы каждое из них имело свою сеть. Ну да ладно - то, что хочет руководство это пожелания, но они, само собой, не специалисты в этом вопросе - решать доверено это дело мне. Так вот. Посоветуйте каким образом лучше структурировать сеть. Дано: в каждом этом сегменте будет свой сервер и по 8 рабочих станций (для начала, дальше они будут расти). Основная задача сервера - базы 1С, к ним подключаются в терминальном режиме. Значится какие есть варианты. Вариант первый (типа: все гениальное просто) Сделать четыре рабочих группы. Адресация у всех одинаковая, типа: 192.168.0.1/254. Вот, в сущности и все. Все, вроде как, должно работать и, на мой взгляд, никаких подводных камней в себе эта структура не несет. Разве что только - не хотелось бы иметь дело с рабочими группами - домены, все же, лучше. Впрочем - если есть аргументы в обратную сторону с удовольствием к ним прислушаюсь. Вариант второй (сложнее, но интереснее - склоняюсь к нему) Сделать четыре доменных дерева в одном лесу. И тут уже возникают вопросы. 1. Будет ли все работать хорошо, если в этой структуре будет один DHCP-сервер? Рабочие станции с других доменов примут динамическую адресацию? Никаких подвохов не будет? А если сделать так: разбиваем диапазон 192.168.0.1/254 на 5 частей (приблизительно по 50 IP) и на каждом контроллере домена делаем свой DHCP который выдает адреса только со своего диапазона? Вроде как отказоустойчивость должна быть отличной? Никаких же конфликтов в этом случае не предвидится? И опять же: была сказана мысль, типа, чтобы все работало так: взяли организацию и отправили ее со своей техникой в далекие края - в этом случае ведь этот домен вообще ничего не связывает с другими, он совершенно автономен и функционален? Я прав? Или есть подводные камни? 2. Насколько сложно настроить, в этой ситуации, доверительные отношения между доменами? Или это просто? Или, опять же - есть подводные камни? Чтобы соответствующие пользователи имели доступ к необходимым ресурсам в других доменах - ведь ничего сложного в этом нет? 3. Как уже говорилось - основная задача серверов - базы данных 1С. Люди работают в терминальном режиме. Вариант когда контроллер домена стоит на отдельном сервере и помимо этого в этом домене есть сервер баз данных - этот вариант пока нецелесообразен, дороговато пока. Отсюда вопрос: контроллер домена работает еще и как сервер баз данных - это нормально, ничего страшного не случится? Что можете сказать по этому поводу? 4. Относительно настройки DNS - на каждом контроллере домена установить планирую DNS. Никаких подвохов в этом не вижу. Что скажете? Ух! Вот такие вопросы, дальше еще может появятся. Уважаемые - будьте добры, посоветуйте - с чем могу сложным столкнутся, что не учел, как можно сделать лучше. Последний раз редактировалось Kravetz; 18.07.2006 в 01:03.

18.07.2006, 13:23	# 5
KomatoZo ::VIP:: Регистрация: 14.05.2005 Сообщения: 939	Kravetz Если их немного, то уедут. Но опять таки при наличии канала до центрального оффиса. Если каналов нет, то в любом случае, уехать они могут только при наличии на каждую контору своего леса. ИМХО. __________________ "Поживем - увидим" - сказал слепой, больной СПИДом... Телепаты в отпуске. Все поголовно. Навсегда. И кому я что должен - всем простил.

18.07.2006, 16:13	# 11
KomatoZo ::VIP:: Регистрация: 14.05.2005 Сообщения: 939	=) Попариться действительно прийдется. Особенно, если не охота потом локти кусать. Начинать все-таки рекомендую с 294. Может быть 293, но я ее еще не читал. 298 как-то не впечатляет, оно скорее для именно проектирования системы безопасности, чем для конкретного внедрения. Скорее 299. 350 - да, если будешь через ISA все делать. Для удаленной площадки можно поднимать отдельный домен, но я уже говорил - не вижу причины. Можно отдельное OU и, как следствие удаленности площадки, отдельный site. DC там можно не ставить, если количество юзеров меньше 50ти, но тогда нужен надежный канал. Именно надежный, а не толстый. Толщина может быть достаточно небольшой при таком количестве ресурсов. Если канал может падать - лучше поставить там DC и настроить кеширование членства в универсальных группах. Ну и т.д. В общем, даже по-хорошему завидую - самому так и не довелось поднять что-либо подобное с нуля. Обычно приходится либо в пределах одного сайта-домена крутиться, либо перекурочивать сделанное кем-то =) __________________ "Поживем - увидим" - сказал слепой, больной СПИДом... Телепаты в отпуске. Все поголовно. Навсегда. И кому я что должен - всем простил.

18.07.2006, 17:11	# 14
gluon Junior Member Регистрация: 09.02.2006 Сообщения: 71	я думаю, с запасом, если, конечно, все не бросятся годовые отчёты строить или что-нибудь в этом роде, в “пиковые” моменты косяки возможны (и дело не столько в железе сколько в архитектуре "1С 7.7 dbf"), но и здесь ситуация облегчается тем, что, насколько я понимаю, все сидят не на одной базе, как уже говорил, не рекомендую использовать этот же сервер в качестве контроллера домена рад бы что-нибудь сказать про лицензирование, но “не приходилось сталкиваться с подобными проблемами” Последний раз редактировалось gluon; 18.07.2006 в 17:17.

18.07.2006, 11:42	# 2
gluon Junior Member Регистрация: 09.02.2006 Сообщения: 71	C DHCP проблем точно не будет. “Сделать четыре доменных дерева в одном лесу” – доверительные отношения установятся автоматом, будут транзитивными и двусторонними. С DNS тоже проблем никаких, делать интегрированные, если не ошибаюсь, областью "репликации DNS" можно сделать все контроллеры леса со службой DNS. Только вот ради каждых 8 рабочих станций держать контроллер домена, ещё и с учётом того, что не рекомендуется службы AD и TS держать на одном сервере... А почему просто не сделать один домен, а остальное, если уж нужно, рулить организационными единицами?

18.07.2006, 13:53	# 7
gluon Junior Member Регистрация: 09.02.2006 Сообщения: 71	Ну так и пускай едут с контроллером, в этом смысле ситуация с лесом или одним доменом мало чем отличаются, всё равно придётся их как то связать (через Интернет… VPN). Если же речь идёт о “полной автономии”, т.е. уехали и связи никакой, то (как уже говорил KomatoZo) решение с лесом не подойдёт, только изолированные домены (леса) и трастинг руками. А вообще при уезде 8 рабочих станций на новом месте можно сеть и с нуля сделать. … ну да, ежели всё же лес… можно с “уезжающими” отправить “клон” первого контроллера первого домена (с нужными ролями) (двоеточие правая скобка)

18.07.2006, 14:58	# 8
Kravetz Newbie Регистрация: 11.04.2006 Сообщения: 26	Ну допустим тогда такой вариант. Значится так: делается один домен, у него один контроллер домена с DHCP и DNS. В этом домене создаю четыре подразделения (по количеству юр.лиц). У них у всех свои 1С базы. А если сделать так - на мой взгляд для каждого подразделения по одному серверу на 1С базы как-то жирно получается - может сделать мощный сервер и все базы разместить там - соответственно дать доступ нужным бухгалтериям только к своим базам. Можно съэкономить на покупке лишних серверов. Я нигде не ошибаюсь - я не специалист в 1С, но, насколько понимаю - каждая бухгалтерия работает со своими базами и никто друг другу не мешает? В этом случае можно было бы обойтись тремя серверами - контроллер домена и два для баз. В принципе - для такого количества рабочих станций (ведь их пока немного) хватило бы и одного хорошего сервера - ведь так? Если начальство хочет - можно разделить доступ из одного подразделения в другое - чтобы не шастали где не нужно, а кому нужно дать разрешение шастать где хочет. Допустим возникает ситуация когда нужно уехать юр.лицу - делаем ему сервер - дополнительный контроллер домена, копируем базы 1С - и пусть катит? Или даже, в принципе - просто копируем базы на носитель. Приходим на новое место, берем новый сервер - поднимаем домен, ставим 1С, копируем обратно базы и все будет работать? Ведь так? Я нигде не ошибаюсь? Ух! Мне кажется, что это оптимальный вариант. Подкажите уважаемые - что думаете по этому поводу. Спасибо Вам за участие в моей проблеме!

18.07.2006, 15:45	# 10
gluon Junior Member Регистрация: 09.02.2006 Сообщения: 71	Всё верно, не понял только точного значения фразы “делаем ему сервер - дополнительный контроллер домена”, судя по следующей фразе “берем новый сервер - поднимаем домен” вроде имеется в виду всё же создание изолированного домена никак не связанного с “первоначальным”, или всё же ещё один контроллер в том же домене, отправляем его на удалённую площадку и налаживаем связь? Тогда действительно придётся слегка попариться… почитать книжки к экзаменам 70-298, 70-299, 70-350… … по 1С (...необходимому количеству и "качеству" серверов) трудно давать рекомендации ничего не зная о исходных данных и условиях проекта (7.7 или 8.0, SQL или dbf , какие конфигурации, сколько пользователей, скольким нужно работать одновременно, что они делают и насколько интенсивно… может и TS не нужен), теоретически на одном сервере может стоять любое количество баз, и перетащить любую из них на другой сервер – не проблема

18.07.2006, 16:14	# 12
Kravetz Newbie Регистрация: 11.04.2006 Сообщения: 26	Да, именно имеется в виду новый домен никак не связанный с изначальным. По поводу 1С - версия 7.7, базы dbf. Комплексная конфигурация. Все работают в терминале - удаленный рабочий стол. Всего около 28 пользователей - это максимум на текущий день. Какой должен быть сервер, чтобы это потянуть. 2*Intel Xeon 2.6 Ghz + 4 Gb ОЗУ - хватит? И еще: хотелось бы иметь лицензионное ПО - стандартный вариант Windows 2003 Server Standart Edition + 5 клиентских лицензий. Отсюда очередной вопрос: клиентов-то больше. Но, тем не менее, будет ли работать ОС без глюков? Или ругнется на число подключений? Соответственно придется докупать еще лицензии. Либо все будет работать и так, просто превышение пользователей это нарушение лицензионного соглашения.