Представьте себе такую ситуацию:
CompanyA приобретает подразделение CompanyB. Компания B увольняет большую часть своих сотрудников для этого подразделения и не помогает при запросе документации. Теперь вы должны использовать ADMT для миграции пользователей, групп, рабочих станций и серверов из дочернего домена CompanyB в Active Directory CompanyA.
Как определить, какие серверы, на которых размещены настраиваемые бизнес-объекты или предварительно упакованные приложения, зависят от других серверов в среде, чтобы можно было соответствующим образом спланировать стратегию миграции? Что-то вроде VMware vCenter Infrastructure Navigator может кое-что из этого, но есть ли другие способы, кроме тратить много времени, просто копаясь?
Ответы могут предполагать, что вся среда Windows работает на vSphere 5.1, хотя ответы для других ситуаций также подходят.
Я был на твоем месте. Нет однозначного ответа на все вопросы.
Вы можете потратить много денег на новый продукт и надеяться, что он знает все о ваших приложениях. Они действительно существуют, и некоторые должны быть неплохими.
Конечно, это может быть не так хорошо, как вам нужно или хочется. И ничто не обнаружит «зависимости», которая вводится ежедневным или еженедельным запланированным сценарием на, казалось бы, несвязанном сервере, который отвечает за получение отрывка из системы заказов на работу и передачу ее по FTP в систему расчета заработной платы. Или физическая линия факса на ящике Linux, которую вы почему-то не заметили во время инвентаризации ...
Мне очень нравится ответ Джо - начиная с каждого отдела и работая с их «опытными пользователями» (которые определенно могут не быть «опытными пользователями» компьютеров), это жизненно важная часть всеобъемлющего проекта открытия. Это восходящий подход. Здесь также вы найдете людей, запускающих критически важные для бизнеса приложения на своих компьютерах, возможно, совместно используемых в их собственной рабочей группе.
Другая часть подхода состоит в том, чтобы войти в каждую машину и запустить что-то, что показывает или даже лучше журналы, TCP и UDP-соединения для $ period_of_time и посмотреть, сможете ли вы поймать трафик (порты и конечные точки, вероятно, не хотят полного захвата сети ), связанных с неизвестными приложениями. То же самое с инвентаризацией запланированных задач, учетных записей служб и т. Д. Это нисходящий подход BFMI.
Из-за возможности асинхронных процессов, не ориентированных на соединение, и вещей, которые не работают на серверах (или клиентских приложений, которые просто запускаются с общих файловых ресурсов), я не думаю, что для этого может быть единый автоматизированный подход. Чтобы сделать это правильно, потребуются трудозатраты. Конечно, вы можете просто нацелиться на 80%, а затем начать миграцию или декомпозицию, имея достаточно информации, чтобы уловить то, что заставляет пользователей кричать, когда они ломаются.
Самый эффективный способ - выключить каждый сервер по очереди и отметить, какие из них выходят из строя, а какие жалуются (но все еще работают).
Это особенно полезно, если у вас заранее есть хороший мониторинг, оповещения, анализ журналов (logstash, splunk и т. Д.) И метрики.
Это не лучшая практика.
Или...
Другой подход - учитывать все службы и процессы, запущенные на каждом сервере, за исключением тех, которые являются общими для каждой машины (базовые процессы / службы Windows, антивирус и т. Д.).