Давно не писал, но вот я снова на волнах интернета.
А так как я все таки какой не какой ИТ - специалист, то в этот раз хотелось бы поведать о своей работе.Да и модно это сейчас стало, типа крутой чувак. Вот и решил отметиться. Как видно из названия, это вроде бы простое задание поставило меня скажем так "раком" аж на целую неделю....
Причины и следствия....
Начнем с того, что решил я настроить главный контроллер домена(хозяин операций), у себя в организации...
Железо не новое установлен изначально криво... 4 винта по 32 гектара, 2 - зеркало, 2 - в свободном плаванье..., стоит 2008 windows server stadart. Как видно основной системный диск зазеркалирован но объем дискового пространства составляет желать лучшего , ну и свободного места соответственно на системном диске, кот наплакал, да еще с недавнего времени поставил WSUS... (восстановил). Так что данное положение дел меня сильно не устраивало.Да еще сама win2008 не устраивает, есть большое желание поставить 2008r2, да и система после, кого то "умного", натянувшего на основной контроллер поверх виртуалку (которую я снес еще в прошлом году) немного скажем так глючила...
Вывод напросился сам - переустановка полная, соответственно передача роли хозяина операции другому контроллера домена, что было с успехом передано виртуальной машине, которая с полгода уже выполняла роль хранилища(т.е. виртуальный контроллер домена).
Передача ролей FSMO прошла благополучно, за одно поднят уровень леса до 2008 с 2003.
Писать подробно о передаче ролей нет смысла, в инете инфы навалом...
netdom query fsmo - набираем и смотрим кто и что.
Но есть печальный опыт, что в такой ситуации отваливается ExchangeServer 2010 причем отваливается на всегда, при последней модификации АД он так и сделал.
Умер по весне резервный КД, правда я к этому был готов и в то время как сервер приказал долго жить стояла уже готова та самая виртуалачка, но в результате умер и Exchange.
В тот момент в системе(АД) столько наворочено было, что мне пришлось полностью руками удалять все записи из АД о Exchange. Благодаря некоторым помощникам, в свое время этот самый Exchange был развернут на КД (виртуально развернут КД на нем сверху Exchange ) и при падении КД он тоже отказался работать, восстановить удалось лишь февральский архив(происходили действия в мае 2011), что выдало сообщение о превышении времени жизни времени захоронения (ну что то так). Еще в данной ситуации помогли кривые руки специалистов приглашенных с "сервиспродукта", удалившие временный Exchange, на тот момент уже работавший. Ну вот в этом году ситуация повторилась, но в этот раз я уже вычистил АД, так что установив новый сервер я был спокоен и думал, что теперь то все работать будет как часы...
Предав роли другому домену, как по книжке заходим на Exchange в оснастку Exchange Management Console. Становимся в дереве Microsoft Exchange на вкладке "настройка серверов" и правой кнопочкой выбираем "Изменить контроллер домена конфигурации..." далее как в книжке через кнопочку "обзор" выбираем домен и обслуживаемый контроллер.
Что и было проделано с успехом, далее для проверки работоспособности вырубаем старого хозяина операций.. и...
И отваливается Exchange, перестает обслуживать почту. Хотя сам в сети и регистрация пользователей проходит в штатном режиме без проблем и задержек...
Идем дальше, раз не работает ищем инфу кого же все таки обслуживает Exchange, для репликации время проходит достаточно, т.к. в рабочее время проводятся все изменения, в вечернее время производиться перезагрузка, потом еще нужно время для того что б откатить изменения.
Get-ExchangeServer -status | fl
результат:
Name : MAIL
DataPath : C:\Program Files\Microsoft\Exchange Server\V14\Mailbox
Domain : contoso.local
Edition : Enterprise
ExchangeLegacyDN : /o=CONTOSO/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL ExchangeLegacyServerRole : 0
Fqdn : MAIL.contoso.local
CustomerFeedbackEnabled : False
InternetWebProxy :
IsHubTransportServer : True
IsClientAccessServer : True
IsExchange2007OrLater : True
IsEdgeServer : False
IsMailboxServer : True
IsE14OrLater : True
IsProvisionedServer : False
IsUnifiedMessagingServer : True
NetworkAddress : {ncacn_vns_spp:MAIL, netbios:MAIL, ncacn_np:MAIL, ncacn_spx:MAIL... }
OrganizationalUnit : contoso.local/AGROMAIL
AdminDisplayVersion : Version 14.2 (Build 247.5)
Site :contoso.local/Configuration/Sites/Default-First-Site-Name
ServerRole : Mailbox, ClientAccess, UnifiedMessaging, HubTransport
ErrorReportingEnabled : FalseE
StaticDomainControllers : {}
StaticGlobalCatalogs : {}
StaticConfigDomainController :
StaticExcludedDomainControllers : {}
CurrentDomainControllers : {ADold.contoso.local}
CurrentGlobalCatalogs : {ADold.contoso.local}
CurrentConfigDomainController : ADold.contoso.contoso.local
ProductID : xxxx-xxx-xxxxxxx-xxxxx
IsExchange2007TrialEdition : False
IsExpiredExchange2007TrialEdition : False
RemainingTrialPeriod : 00:00:00
IsValid : True
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=MAIL,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=AGROMIR,CN=MicrosoftExchange, CN=Services,CN=Configuration,DC=contoso,DC=local
Identity : MAIL
Guid : xxXXxXxx-XXxx-xxxX-xXxX-XXXXXXXXXXXX
ObjectCategory : contoso.local/Configuration/Schema/ms-Exch-Exchange-Server
ObjectClass : {wer, server, msExchExchangeServer}
WhenChanged : 04.10.2012 11:16:52
WhenCreated : 06.04.2012 16:22:01
WhenChangedUTC : 04.10.2012 7:16:52
WhenCreatedUTC : 06.04.2012 12:22:01
OrganizationId :
OriginatingServer : ADold.contoso.local
где MAIL - сервер Exchange, ADold.contoso.local - старый контроллер домена, бывший хозяин операций. Как видно из примера смена обслуживающего контроллера домена не произошла, ну и в последствии не происходит, после как в книжке написано, что раз в 8 часов она происходит автоматически, на другой контроллер.
Что же делать? Извечный вопрос, порывшись в инете, да полистав литературу , особенно помогло Get-Help * и т.д. нашел на одном англоязычном форуме, что надо прописать StaticDomainControllers и за одно StaticGlobalCatalogs, ну и т.д.
Что я и принялся делать... Set-ExchangeServer -Identity: Mail -StaticDomainControllers: NewCD.contoso.local
где NewCD.contoso.local - новый хозяин операций...
Что происходит: а происходило следующее, после прописывания статического указания Mail, становиться в ступор и тупо думает куда ему идти, я перезапускал и службу топологии, можно сказать и танцы с бубном, ни чего не помогало. Тупо не работает причем сам сервер долго отвечал, доходило до того, что сервер перестал отвечать и пускать даже на сервер, и я с горем пополам возвращал все обратно: Set-ExchangeServer -Identity: Mail -StaticDomainControllers:$Null
если сервер позволял, в общем на тр....
Дошло до того, что вычитал как Микрософт не рекомендует на виртуальных машинах разворачивать контролеры доменов...(ну не вычитал а на курсах преподаватель говорил).
Развернул еще один контроллер домена, тут как раз попался релиз Win2012, развернутый сервер быстро стал еще одним контроллером домена. Не помогло.
Решил проверить
Get-ADServerSettings | fl
И какого было мое удивление когда он мне выдал:
DefaultGlobalCatalog :
PreferredDomainControllerForDomain : {}
DefaultConfigurationDomainController :
DefaultPreferredDomainControllers : {}
UserPreferredGlobalCatalog :
UserPreferredConfigurationDomainController :
UserPreferredDomainControllers : {}
RecipientViewRoot :
ViewEntireForest : True
WriteOriginatingChangeTimestamp : False
WriteShadowProperties : False
Identity :
IsValid : True
а за двоеточием пустота...
Следующее действие, которое производилось это: Set-ADServerSettings -PreferredServer NewCD.contoso.local применяем и смотрим Get-ADServerSettings пишет о том, что обслуживаемый домен есть NewCD и так далее все как положено, что удивительно OriginatingServer : NewCD.contoso.local, но основной обслуживаемый домен в эксчендже так и не сменился... при прописывании статики происходит все тоже самое ...
Решил все полностью, привести в порядок начал с DNS, вычистил полностью все ошибки, поставил обновление и удаление устаревших записей 1 день... после чего в филиалах отвалился эксчендж при танцах с бубнами выяснилось что в ДНСе удалилась запись о самом эксчендже, что в нашей ситуации не есть "гуд", быстро восстановив данную запись и восстановление работы филиалов, было решено убрать Win2012 из контроллеров домена и поставить 2008r2, что было и произведено. Благо Exchange все это время работал, пока не трогали старый контроллер домена, почта ходила во всех направлениях без проблем.
Опустим все манипуляции проводившиеся за это время типа setup /PrepareAD, DCDIAG и др.
Причем DCDIAG ошибок не показал.
После чего передал роли новому контроллеру домена на основе Win2008r2 (это для того, чтоб исключить влияние виртуального сервера) но ситуация сильно не поменялась.
Что еще странно, пока производились все манипуляции с Exchange, каким то способом исчез мой локальный профиль на самом Exchange, да и дело то не в этом. Странность заключалась в том, что в организации, есть еще один админ с такими же правами как и я(вернее я наделил его этими правами, чтоб зайти под его учеткой на сервер), а при входе на сервер Exchange он писал что данной учетной записи нет прав.Странность в другом, что Exchange не применял обновление даже при включенном старом контроллере домена.
Пришлось мне часами сидеть и ждать формирования временного профиля пользователя, слава богу хоть пускал...это в режиме когда статику прописываешь.
Для исправления выполняем следующее:
.
.
.
CurrentDomainControllers : {ADold.contoso.local, NewCD.contoso.local, DC.contoso.local}
CurrentGlobalCatalogs : {ADold.contoso.local, NewCD.contoso.local, DC.contoso.local}
.
.
.
Соответственно при отключении старого КД все работает, можно приступать к переустановке старого контроллера домена в режиме ядра и запасаться бубном. :)))))
Особая благодарность Дмитрию Попову "DimSE™" (Мастер-Инструмет) в помощи при исправлении данной ситуации.
P.S. очерк писал в первую очередь для себя, чтоб потом долго не рыть в инете в поисках, если пригодится еще кому то буду рад.
А так как я все таки какой не какой ИТ - специалист, то в этот раз хотелось бы поведать о своей работе.Да и модно это сейчас стало, типа крутой чувак. Вот и решил отметиться. Как видно из названия, это вроде бы простое задание поставило меня скажем так "раком" аж на целую неделю....
Причины и следствия....
Начнем с того, что решил я настроить главный контроллер домена(хозяин операций), у себя в организации...
Железо не новое установлен изначально криво... 4 винта по 32 гектара, 2 - зеркало, 2 - в свободном плаванье..., стоит 2008 windows server stadart. Как видно основной системный диск зазеркалирован но объем дискового пространства составляет желать лучшего , ну и свободного места соответственно на системном диске, кот наплакал, да еще с недавнего времени поставил WSUS... (восстановил). Так что данное положение дел меня сильно не устраивало.Да еще сама win2008 не устраивает, есть большое желание поставить 2008r2, да и система после, кого то "умного", натянувшего на основной контроллер поверх виртуалку (которую я снес еще в прошлом году) немного скажем так глючила...
Вывод напросился сам - переустановка полная, соответственно передача роли хозяина операции другому контроллера домена, что было с успехом передано виртуальной машине, которая с полгода уже выполняла роль хранилища(т.е. виртуальный контроллер домена).
Передача ролей FSMO прошла благополучно, за одно поднят уровень леса до 2008 с 2003.
Писать подробно о передаче ролей нет смысла, в инете инфы навалом...
netdom query fsmo - набираем и смотрим кто и что.
Но есть печальный опыт, что в такой ситуации отваливается ExchangeServer 2010 причем отваливается на всегда, при последней модификации АД он так и сделал.
Умер по весне резервный КД, правда я к этому был готов и в то время как сервер приказал долго жить стояла уже готова та самая виртуалачка, но в результате умер и Exchange.
В тот момент в системе(АД) столько наворочено было, что мне пришлось полностью руками удалять все записи из АД о Exchange. Благодаря некоторым помощникам, в свое время этот самый Exchange был развернут на КД (виртуально развернут КД на нем сверху Exchange ) и при падении КД он тоже отказался работать, восстановить удалось лишь февральский архив(происходили действия в мае 2011), что выдало сообщение о превышении времени жизни времени захоронения (ну что то так). Еще в данной ситуации помогли кривые руки специалистов приглашенных с "сервиспродукта", удалившие временный Exchange, на тот момент уже работавший. Ну вот в этом году ситуация повторилась, но в этот раз я уже вычистил АД, так что установив новый сервер я был спокоен и думал, что теперь то все работать будет как часы...
Предав роли другому домену, как по книжке заходим на Exchange в оснастку Exchange Management Console. Становимся в дереве Microsoft Exchange на вкладке "настройка серверов" и правой кнопочкой выбираем "Изменить контроллер домена конфигурации..." далее как в книжке через кнопочку "обзор" выбираем домен и обслуживаемый контроллер.
Что и было проделано с успехом, далее для проверки работоспособности вырубаем старого хозяина операций.. и...
И отваливается Exchange, перестает обслуживать почту. Хотя сам в сети и регистрация пользователей проходит в штатном режиме без проблем и задержек...
Идем дальше, раз не работает ищем инфу кого же все таки обслуживает Exchange, для репликации время проходит достаточно, т.к. в рабочее время проводятся все изменения, в вечернее время производиться перезагрузка, потом еще нужно время для того что б откатить изменения.
Get-ExchangeServer -status | fl
результат:
Name : MAIL
DataPath : C:\Program Files\Microsoft\Exchange Server\V14\Mailbox
Domain : contoso.local
Edition : Enterprise
ExchangeLegacyDN : /o=CONTOSO/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL ExchangeLegacyServerRole : 0
Fqdn : MAIL.contoso.local
CustomerFeedbackEnabled : False
InternetWebProxy :
IsHubTransportServer : True
IsClientAccessServer : True
IsExchange2007OrLater : True
IsEdgeServer : False
IsMailboxServer : True
IsE14OrLater : True
IsProvisionedServer : False
IsUnifiedMessagingServer : True
NetworkAddress : {ncacn_vns_spp:MAIL, netbios:MAIL, ncacn_np:MAIL, ncacn_spx:MAIL... }
OrganizationalUnit : contoso.local/AGROMAIL
AdminDisplayVersion : Version 14.2 (Build 247.5)
Site :contoso.local/Configuration/Sites/Default-First-Site-Name
ServerRole : Mailbox, ClientAccess, UnifiedMessaging, HubTransport
ErrorReportingEnabled : FalseE
StaticDomainControllers : {}
StaticGlobalCatalogs : {}
StaticConfigDomainController :
StaticExcludedDomainControllers : {}
CurrentDomainControllers : {ADold.contoso.local}
CurrentGlobalCatalogs : {ADold.contoso.local}
CurrentConfigDomainController : ADold.contoso.contoso.local
ProductID : xxxx-xxx-xxxxxxx-xxxxx
IsExchange2007TrialEdition : False
IsExpiredExchange2007TrialEdition : False
RemainingTrialPeriod : 00:00:00
IsValid : True
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=MAIL,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=AGROMIR,CN=MicrosoftExchange, CN=Services,CN=Configuration,DC=contoso,DC=local
Identity : MAIL
Guid : xxXXxXxx-XXxx-xxxX-xXxX-XXXXXXXXXXXX
ObjectCategory : contoso.local/Configuration/Schema/ms-Exch-Exchange-Server
ObjectClass : {wer, server, msExchExchangeServer}
WhenChanged : 04.10.2012 11:16:52
WhenCreated : 06.04.2012 16:22:01
WhenChangedUTC : 04.10.2012 7:16:52
WhenCreatedUTC : 06.04.2012 12:22:01
OrganizationId :
OriginatingServer : ADold.contoso.local
где MAIL - сервер Exchange, ADold.contoso.local - старый контроллер домена, бывший хозяин операций. Как видно из примера смена обслуживающего контроллера домена не произошла, ну и в последствии не происходит, после как в книжке написано, что раз в 8 часов она происходит автоматически, на другой контроллер.
Что же делать? Извечный вопрос, порывшись в инете, да полистав литературу , особенно помогло Get-Help * и т.д. нашел на одном англоязычном форуме, что надо прописать StaticDomainControllers и за одно StaticGlobalCatalogs, ну и т.д.
Что я и принялся делать... Set-ExchangeServer -Identity: Mail -StaticDomainControllers: NewCD.contoso.local
где NewCD.contoso.local - новый хозяин операций...
Что происходит: а происходило следующее, после прописывания статического указания Mail, становиться в ступор и тупо думает куда ему идти, я перезапускал и службу топологии, можно сказать и танцы с бубном, ни чего не помогало. Тупо не работает причем сам сервер долго отвечал, доходило до того, что сервер перестал отвечать и пускать даже на сервер, и я с горем пополам возвращал все обратно: Set-ExchangeServer -Identity: Mail -StaticDomainControllers:$Null
если сервер позволял, в общем на тр....
Дошло до того, что вычитал как Микрософт не рекомендует на виртуальных машинах разворачивать контролеры доменов...(ну не вычитал а на курсах преподаватель говорил).
Развернул еще один контроллер домена, тут как раз попался релиз Win2012, развернутый сервер быстро стал еще одним контроллером домена. Не помогло.
Решил проверить
Get-ADServerSettings | fl
И какого было мое удивление когда он мне выдал:
DefaultGlobalCatalog :
PreferredDomainControllerForDomain : {}
DefaultConfigurationDomainController :
DefaultPreferredDomainControllers : {}
UserPreferredGlobalCatalog :
UserPreferredConfigurationDomainController :
UserPreferredDomainControllers : {}
RecipientViewRoot :
ViewEntireForest : True
WriteOriginatingChangeTimestamp : False
WriteShadowProperties : False
Identity :
IsValid : True
а за двоеточием пустота...
Следующее действие, которое производилось это: Set-ADServerSettings -PreferredServer NewCD.contoso.local применяем и смотрим Get-ADServerSettings пишет о том, что обслуживаемый домен есть NewCD и так далее все как положено, что удивительно OriginatingServer : NewCD.contoso.local, но основной обслуживаемый домен в эксчендже так и не сменился... при прописывании статики происходит все тоже самое ...
Решил все полностью, привести в порядок начал с DNS, вычистил полностью все ошибки, поставил обновление и удаление устаревших записей 1 день... после чего в филиалах отвалился эксчендж при танцах с бубнами выяснилось что в ДНСе удалилась запись о самом эксчендже, что в нашей ситуации не есть "гуд", быстро восстановив данную запись и восстановление работы филиалов, было решено убрать Win2012 из контроллеров домена и поставить 2008r2, что было и произведено. Благо Exchange все это время работал, пока не трогали старый контроллер домена, почта ходила во всех направлениях без проблем.
Опустим все манипуляции проводившиеся за это время типа setup /PrepareAD, DCDIAG и др.
Причем DCDIAG ошибок не показал.
После чего передал роли новому контроллеру домена на основе Win2008r2 (это для того, чтоб исключить влияние виртуального сервера) но ситуация сильно не поменялась.
Что еще странно, пока производились все манипуляции с Exchange, каким то способом исчез мой локальный профиль на самом Exchange, да и дело то не в этом. Странность заключалась в том, что в организации, есть еще один админ с такими же правами как и я(вернее я наделил его этими правами, чтоб зайти под его учеткой на сервер), а при входе на сервер Exchange он писал что данной учетной записи нет прав.Странность в другом, что Exchange не применял обновление даже при включенном старом контроллере домена.
Пришлось мне часами сидеть и ждать формирования временного профиля пользователя, слава богу хоть пускал...это в режиме когда статику прописываешь.
Но танцы с бубнами заканчиваются...Вычистил я ДНС полностью, поставил новый контроллер домена (не виртуальный). Все как бы "отличненько" работает, но Exchange такая сволочь при выключении старого КД так и продолжает отваливаться, т.е как выдавал ошибку так выдавал. Тут я решаю проверить ошибки службы топологии Microsoft Exchange Active Directory, но и это сильно не помогла ... хотя если бы не рыл в эту сторону то наверное и не нашел бы как исправить ситуацию: Конфигурационный контроллер домена, указанный в вызове SetConfigDCName недоступен, рыть оказалось надо в сторону прав и локальных политик...
Для исправления выполняем следующее:
- Откройем оснастку "Локальная политика безопасности" для контроллера домена, на который хотите переориентировать сервер Exchange или просто добавить в список обслуживаемых.
- Развернем "Назначение прав пользователя" на панели результатов дважды щелкните "Управление журналами аудита и безопасности".
- Проверяем, что включены обе группы: Серверы Exchange и/или Серверы предприятия Microsoft Exchange.
- Если нет таких групп добавляем, смело и делаем "gpupdate /force" и перезагрузку всех КД (последовательно).
.
.
.
CurrentDomainControllers : {ADold.contoso.local, NewCD.contoso.local, DC.contoso.local}
CurrentGlobalCatalogs : {ADold.contoso.local, NewCD.contoso.local, DC.contoso.local}
.
.
.
Соответственно при отключении старого КД все работает, можно приступать к переустановке старого контроллера домена в режиме ядра и запасаться бубном. :)))))
Особая благодарность Дмитрию Попову "DimSE™" (Мастер-Инструмет) в помощи при исправлении данной ситуации.
P.S. очерк писал в первую очередь для себя, чтоб потом долго не рыть в инете в поисках, если пригодится еще кому то буду рад.
