Дисковый дизайн VMDK Exchange 2010
Возможности состоят в том, что Вы имеете брандмауэр на и вероятно блокируете ICMP. Эхо-запросы ICMP (ping) не являются предпосылкой для возможности соединения. Так как это заботится о - по Вашему основному вопросу.
Что касается того, почему можно соединиться, и они не могут - мы нуждаться в большем количестве информации. Я предполагаю, что Вы - все на той же внутренней сети и нет ничего различного в Вашем соединении, чем их. Учетные записи других пользователей добавляются к Удаленному рабочему столу, позволяют список?
Рекомендуется разделить файл подкачки, базы данных и журналы на отдельные шпиндели. Это означает размещение трех отдельных VMDK на трех отдельных LUN. Для 100 пользователей это может не потребоваться. Это не тонна, но вы все равно должны использовать perfmon (или аналогичный) для профилирования требований к хранилищу / оперативной памяти вашего сервера. Если да, то вы будете знать, сколько операций ввода-вывода в секунду вам нужно, и тогда базовая геометрия диска станет простым математическим уравнением.
Если бы вы использовали электронную таблицу Microsoft для расчета ваших lun, я бы сопоставил это. Если электронная таблица требует 4 lun или что-то в этом роде, я бы создал vmdk для каждого lun и, вероятно, поместил бы каждый vmdk в свой lun. Это во многом будет зависеть от того, какая у вас дисковая система / san, а также от множества других факторов.
Для 100 пользователей мои системы Exchange на базе VMWare выглядят так ...
[VMDK] - 72 ГБ с тонким выделением ресурсов для операционной системы
[VMDK] - 40 ГБ с тонким предоставлением для журналов Exchange
[VMDK] - 200 ГБ + тонкое или толстое выделение для базы данных Exchange
Не увлекайтесь попытками перехитрить планировщик вашего гипервизора. Я очень сомневаюсь, что ваша установка создаст большую нагрузку на нормальный SAN (хотя вы не упомянули марку / модель вашего хранилища ...)