Когда необходимо создать дополнительный домен в лесу?
Хорошо, поэтому в случае, если кто-то натыкается на эту запись, все имело отношение к связанным файлам DLL некоторого поврежденного IE8 в резервном копировании.
Наконец вычисленный то, которые и быстрое переустанавливают на IE8, кажется, добилось цели.
Creating another domain adds complexity. To the extent that you are able to maintain a single domain environment you will limit complexity. I find that administrative activities are easier in a single domain environment.
Visual organization ("a tidier organization") could be accomplished with other features, like organizational units (OUs) in Active Directory. Personally, I wouldn't consider such "tidiness" reason enough to create a second domain.
Just about any delegation of control scenario that you can envision in a multi-domain environment can be handled in a single domain by delegating control at an OU.
From a logon efficiency perspective it makes sense to have Domain Controller (DC) computers at a location for whatever domains will be used in that location. If you are going to have users travelling between locations you will need more DCs (one for each domain, at minimum) if you have a multi-domain environment.
Cross-forest Group Policy Objects (GPOs) have, in my experience, been somewhat flaky. You will need a DC from the domain where a GPO is hosted well-connected to machines that apply GPOs from that domain. That may also cause to need more DCs in a multi-domain environment as compared to a single domain.
My opinion is that a multi-domain environment is only necessary when you require multiple domain-level password policies (and can't make use of fine-grained password policy within a single domain for some technical reason), or when the domain replication traffic would be so extreme as to warrant isolation to limit replication traffic.
Edit:
If you really do need separation, legally or organizationally, then a separate Forest for the other company is really the only way to go. Separate domains in the same forest offer no practical separation, aside from partitioning the replication of the Directory.
As your question is currently posed, it sounds to me like you could get as much mileage out of setting up a new Site in Active Directory as you would with a new domain. You'd create a new domain controller at the new physical location, but in the same domain and forest, and set it up to serve the new site in question (through the Active Directory Sites and Services management tool).
Of course, without a clarification on Mathias' comment, I'm not comfortable saying that with any certainty. If these really are two different companies, you should probably have a forest for each company, even if they collaborate tightly. Binding them into one AD forest could have undesirable legal or compliance implications that might outweigh the advantage of simple Active Directory management. And then there's the question of what happens when/if these two companies go their separate ways. Who "owns" the existing forest, how do you perform proper disengagement, who pays for that work, and who pays to set up a new forest for the company that now doesn't have one?
Federated services exist precisely to allow for interaction between companies' forests and cross-use of resources in those different forests, so that separate organizations don't need to share the same forest to work together. It a more complicated setup, and more to manage, but if there really are two companies in play here, it's the setup I'd recommend - two separate forests using federated services to connect to each other. Less hassle, mess and politics involved when each organization owns their own forest, and connect to each other using federated services, and no worries about what happens after the collaboration ends.
Похоже, что большинство ваших вопросов нужно адресовать скорее бизнес-уровню, чем техническому. Во-первых, если бизнес намеревается вырастить вторую компанию, а затем отделиться, когда они вырастут, отдельный домен может быть полезен в этом сценарии, чтобы помочь им разделиться.
Если у вас нет жестких требований безопасности, никогда не используйте RODC, они являются просто дополнительными административными расходами, и почти во всех сценариях не стоит беспокоиться. Отлично в теории, мучительно на практике. По крайней мере, пробуйте и поймите, во что вы ввязываетесь, прежде чем делать это в любом случае.
Если компании намерены оставаться вместе, это будет зависеть от того, насколько разделенной должна быть ИТ-администрация. Администратор домена часто используется, часто используется чрезмерно, но также часто необходим для ключевых сотрудников ИТ-организации. Единый домен означает, что эта мощная группа пользователей обеспечит полный доступ в этом домене ко множеству административных консолей и будет охватывать обе части компании. Изменение тех значений по умолчанию, где это разрешено, может быть даже более беспорядочным, чем дополнительные усилия администратора по управлению двумя дочерними доменами. Поэтому, если вы считаете, что будет требование о разделении административной ответственности и этот уровень контроля (для каждой компании), вероятно, станет жестким требованием, тогда отдельные домены - лучший вариант. Если этого никогда не произойдет, и две ИТ-организации могут работать в гармонии (здесь ключ к контролю за хорошей коммуникацией и совместными изменениями), или только одна ИТ-организация может управлять / совместно использовать две компании, тогда придерживайтесь одной.
В настоящее время я помогаю одной Компания, имеющая около 12 отдельных доменов, региональную ИТ-поддержку и более 60000 пользователей, снова объединяется в один домен, потому что у них нет необходимости оставаться отдельными, а это болезненный процесс. Таким образом, первые решения должны быть правильными, и хотя вы не всегда можете спланировать то, что бизнес может сделать через 10 или даже 5 лет, задавайте вопросы на всех уровнях сейчас, документируйте их ответы и хорошо готовьтесь.