Службы удаленных рабочих столов 2008 — ошибка 4105 (проблема с сервером лицензий)
Это могло бы быть чрезмерно упрощенно для того, что Вы после, поскольку я не слишком знаком с резервными базами данных
но, пока экземпляр, необходимо смочь запросить v$instance, просматривают и получают состояние базы данных, например,
SELECT INSTANCE_NAME, DATABASE_STATUS, INSTANCE_ROLE, ACTIVE_STATE FROM v$instance;
Согласно этой ссылке и этому, атрибуты, которые Вы упоминаете, были сначала начаты с Windows Server 2008; таким образом, да, обновление AD схемы к уровню 2008 года должно решить Вашу проблему.
Это - полностью безопасная работа, даже если Вы не планируете добавить какой-либо DC 2008 к домену в ближайшее время. Просто удостоверьтесь, что весь Ваш DCS онлайн, репликация правильно работает, DC, содержащий роль Хозяина схемы, доступен, и у Вас есть права администратора Администратора и Схемы Предприятия.
BTW, необходимо выполнить ADPREP на одном из существующих контроллеров домена 2003, не на рядовом сервере 2008.
"Ключи защиты", которые Вы упоминаете, кажется, атрибуты LDAP (я не лично знаком с этими, но они следуют стандартному соглашению о присвоении имен), таким образом, необходимо будет использовать adsiedit.msc (доступный в Наборе Ресурса Windows Server 2003) для достигания их.
Обновление схемы через adprep является хорошей идеей. А также навлекая эти атрибуты это даст новой схеме постельные принадлежности в период перед созданием перемещения к DCS 2008. Как Massimo сказал, это - безопасная работа, но удостоверьтесь, что у Вас есть жизнеспособное резервное копирование Вашего AD прежде, чем сделать его (и также что Вы знаете, что можно восстановить от него!) в случае, если Вы получаете сбой питания или что-то еще противное, происходит отчасти через.
А также обновление схемы - Вы перемещали поле TS в новый OU в каком-либо моменте времени? Несколько MS Services становятся недовольными, когда Вы делаете это, и - если Вы не перезапустили сервисы или перезагрузили поле - может дать ошибочное поведение. Я считал бы это общей хорошей практикой для перезапуска любых сервисов, которые взаимодействуют с AD после Компьютерной операции пересылки.
-
1Отлично. I' ll дают этому попытку в эти выходные и сообщают всем. – Russ Warren 12 February 2010 в 21:39
adprep, обновление схемы и т. Д., Я думаю, не решит вашу проблему. обновление схемы не является проблемой, потому что вам придется сделать это также, если появятся новые DC.
в моем случае у меня есть собственный 2008 r2, конечно, перенесенный с 2000 на 2003, на 2008 R2, а также 2008 r2 ts, ts lic, все nazive в 2008 r2.
, но тот же эффект. не видите никаких проблем в реальной среде, но также регистрируете эту информацию на сервере лицензий ts.
поэтому, если вы посмотрите глубже в свою инфраструктуру, ты увидишь это - вновь созданная учетная запись пользователя - некоторые из ваших аккаунтов действительно имеют несколько атрибутов msTS.
На самом деле я вижу, что все учетные записи пользователей в организационных единицах с отсутствующими атрибутами находятся в одних и тех же группах. То же OU. поэтому я думаю, что эта проблема возникает в самостоятельно созданных организационных подразделениях, где существует одна проблема, такой отсутствующий параметр наследуемых прав, отсутствующий параметр безопасности.
Я сейчас тестирую его.
что я хочу сказать всем:
ваша система в этой среде ошибок не должна обновляться, adprep, schemaprep, и т.п. посмотрите настройки безопасности на ваших ous, пользовательских объектах.
mathias rühn - kopyczynski
добавить: Решением было предоставить права безопасности для пользовательских объектов, у которых отсутствуют три атрибута msTS: ЧИТАТЬ и ЗАПИСАТЬ сервер лицензий сервера терминалов для группы терминал-лицензионный сервер.
если вы снова войдете в систему через удаленный рабочий стол или Citrix, три атрибута будут созданы для конкретного пользователя и заполнены информацией.
также недавно созданный ous имел проблему в одной из моих инфраструктур. мне пришлось вручную сделать эту настройку на втором уровне ous.