В настоящий момент архитектура 1С v7.7 выглядит следующим образом. Существует большое количество пользовательских модулей (кадры, зарплата, автохозяйство и т. д.), связанных с соответствующими базами данных под управлением MS SQL 2000 (существует отдельный сервер БД). Всевозможные конфигурации и рабочие каталоги пользователей расположены на другом сервере (назовём его файл-сервером). Но этот файл-сервер служит не только для нужд 1С. Информация, связанная с 1С, занимает 13 Гб при общем объёме ресурса 800 Гб. Из-за того, что файл-сервер юзают и другие приложения, на нём возникает постоянный дефицит свободного места. В связи с этим было принято решение выделить для 1С отдельный файл-сервер. При этом существует также вариант размещения всей связанной с 1С информации на сервере БД (MS SQL 2000) в отдельном разделе, что с моей точки зрения не есть гуд. Все советы понятны нам, администраторам и программистам. А начальству, которое в конечном счёте принимает решение о выделении отдельного сервера, нужно что-то вроде официальной рекомендации от 1С на их официальном сайте. Пока поиск в интернете ничего не дал...

Если терминал не предполагается, то ИМХО можно и на серваке со скулем метаданные держать.

Терминал не предполагается. Но тогда будет существовать теоретическая, правда, очень маленькая, возможность доступа непосредственно к базам данных MS SQL обычных пользователей метаданных.

(1)+ Точнее организация терминального доступа отдельная.
А метаданные и сопктствующую лабуду можно вместе со скулем держать.
По крайней мере у меня так, правда поменьше объемом.

(2) Ну разве что.
Хотя открытие шары на каталог метаданных вряд ли увеличит вероятность достучаться до скульных данных непосредственно.

А где-то можно об этом на каком-то сайте 1С почитать?

Вот этого не знаю.
А теоретическая возможность достучаться до скульных данных и без открытия шары есть. Тут уж больше от организационных мер зависит. Если пароль админа домена/компа не раздаете неправо и налево :).

от 200 пользователей нужен не загруженный   другими сетевыми
файловыми задачами сервер. обслуживание файловых блокировок (lck) становится критичной задачей. и возможны ситуации блокировки пользователей (нечетное кол-во блокировок на пользователя)

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

От двухсот одновременно работающих?

(8)
да.

У нас где-то 100-150 получается.

(0) А в чем Вам видятся минусы размещения метаданных на одной машине с SQL сервером? (При условии нормально настроенных прав доступа, разделении хранилищ SQL/конфигурации по разным физическим носителям и наличии запаса по ресурсам машины)
Я вижу больше плюсов в одном сервере:
- ниже вероятность отказа
- возможность сделать/поднять полный бэкап на одной машине
- возможность делать регламентные операции/реструктуризации локально на сервере/через терминальный доступ

Опишу один из минусов. В силу различных причин существут вероятность перезагрузки этого сервера метаданных. Вместе в ним придётся перезагружать и Скуль, что не есть хорошо...

(12) А в чем минус перезагрузки SQL сервера?? Если мы перезагружаем файловый сервер с метаданными, все равно никто с SQL работать не сможет.
Или у вас на SQL-е работает еще что-то помимо 1С? (об этом в условия(0) не написано)
Если SQL используется не только как хранилище баз 1С - это другой разговор

Кроме 1С, действительно, ничего нет. Но там ещё постоянно джобы по резервному копированию крутятся. Так что, на мой взгляд, лучше Скуль лишний раз не тревожить.

(0) Скуль отдельно должен крутиться. И в вашем случае это необсуждается. Берите железку под терминал и на нем держите каталоги. ЗиК держите только в дбф формате.
Зачем изобретать велосипед?.. Непонимаю я этих админов.

(0) Рабочий каталог пользователя должен лежать на той машине, где он запускает 1С.