вторник, 13 декабря 2011 г.

SCSM Ошибка "Недопустимая длина массива знаков Base-64." при добавлении отчёта в "избранные отчёты"

Столкнулся со странной ошибкой при попытке добавить отчёт SCSM в избранные отчёты. Настроил параметры отчёта, нажал добавить в "Избранные отчёты". Назвал отчёт следующим образом "Все инциденты находящиеся в работе с понедельника текущей недели по сегодняшний день" и нажал "ОК".
Отчёт добавился в избранные, но при переходе на вкладку столкнулся с ниже приведённой ошибкой.

Дата: 08.12.2011 10:06:11
Приложение: System Center Service Manager
Версия приложения: 7.0.6555.0
Серьезность: Ошибка
Сообщение:
Недопустимая длина массива знаков Base-64.
System.FormatException: Недопустимая длина массива знаков Base-64.
в System.Convert.FromBase64String(String s)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.SrsDataAdapterBase.TryGetInstanceId(IDictionary`2 parameters, String& instanceId)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.EnterpriseFavoriteReportAdapter.GetDataFromSRS(ServiceManagerReportingGroup reportingGroup, AdapterQueryParameters queryParameters)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.DataAdapters.SrsDataAdapter`1.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.SdkNodeProvider.GetDataFromAdapter(Uri adapterAddress, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs)
в Microsoft.EnterpriseManagement.UI.SdkDataAccess.SdkNodeProvider.GetNode(Uri providerRoot, NavigationModelNodeBase parentNode, String nodeName)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationNodeProvider.GetNode(Uri providerRoot, Uri nodeLocation)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.GetNode(DataQueryBase query, IDictionary`2 parameters)
в Microsoft.EnterpriseManagement.ConsoleFramework.NavigationModelAdaptor.DoAction(DataQueryBase query, IList`1 dataSources, IDictionary`2 parameters, IList`1 inputs, String outputCollectionName)
в Microsoft.EnterpriseManagement.UI.DataModel.QueryQueue.StartExecuteQuery(Object sender, ConsoleJobEventArgs e)
в Microsoft.EnterpriseManagement.ServiceManager.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)

Анамнез:
  • Избранные отчёты с англ. наименованиями успешно создаются, добавляются во вкладку избранные и успешно работают;
  • Проблема с отчётами только с русскоязычным наименованием;
  • Проверил Collation SQL Server и БД Cyrillic_General_100_CI_AS, а Collation SSRSLatin_General_CI_AS_KS_WS (SSRS устанавливался в режиме Native в конфигурации по-молчанию);
Причина:
Не поддерживаются наименования отчётов на русском языке длиннее 20 символов (по крайне мере доказал на своем опыте 32, 28, 23 не вошло - ошибку см. выше.);

Что делать:
На сервере, где установлен DW заходим в консоль управления SQL сервер, находим в базе DWStagingAndConfig таблицу dbo.FavoriteReport.

В ней выполняем запрос:
SELECT * 
FROM DWStagingAndConfig.dbo.FavoriteReport
WHERE DWStagingAndConfig.dbo.FavoriteReport.FavoriteReportName='Имя_отчёта_вызывающего_ошибку'

Находим в результатах поле FavoriteReportId и выполняем следующий запрос:
DELETE FROM DWStagingAndConfig.dbo.FavoriteReport
WHERE DWStagingAndConfig.dbo.FavoriteReport.FavoriteReportId=' FavoriteReportId_отчёта_вызывающего_ошибку';


Обновляем закладку избранные отчёты (F5): отчёт вызывающий ошибку исчез.
Ну и создавать короткие русскоязычные имена для отчётов. Кстати, подобных проблема с англ. языком я так и не заметил.

http://social.technet.microsoft.com/Forums/ru-RU/infrastructureru/thread/9f094565-7ad5-4511-a7fc-31f9ebe0f069

Split-Brain DNS: как выбрать правильную реализацию?

Последнее время в моей практике участились случаи, когда ИТ специалисты, реализуя архитектуру системы разрешения доменных имён до конца не осознают всех нюансов, с которыми они столкнуться в процессе эксплуатации того или иного решения. Поэтому, решил ещё раз кратко осветить эту тему.

Как пример рассмотрим следующий сценарий:
существует корпоративная сеть с пользователями, которым необходим доступ к различным интернет ресурсам, а так же веб-сайтам компании, размещенными в DMZ и опубликованных в интернет;

 
Основная цели:
  • обеспечить свободное разрешение доменных имён интернет для пользователей корпоративной сети
  • обеспечить доступ корпоративных пользователей изнутри и снаружи к веб-сайтам компании
  • предотвратить возможность для внешних пользователей разрешать имена внутренних ресурсов компании

  
Существует три возможных сценария построения системы разрешения доменных имён:

  • Одинаковое имя DNS внутреннего и внешнего пространства имён организации (Пример: ABC.COM);
  • Разное имя DNS для внутреннего и внешнего пространства имён организации, для разрешения имён используется Conditional Forwarding (Пример: ABC.LOCAL и ABC.COM);
  • Делегированное имя зоны DNS для внутреннего пространства имён DNS (Пример: AD.ABC.COM и ABC.COM);

  
Одинаковое имя DNS внутреннего и внешнего пространства имён организации (Пример: ABC.COM)

Самый простой способ реализации. На внутреннем DNS размещаются A записи веб-ресурсов компании. Когда корпоративные пользователи запрашивают какой либо ресурс, размещённый в DMZ и опубликованный наружу, внутренний DNS отдаёт адрес, указанный в “А” записи, созданной администратором на внутреннем DNS сервере. Внешний DNS служит для обслуживания только внешних пользователей, динамические обновления записей на нём запрещены. Передача зон отключена.

Плюсы:
  • Одинаковые имена для ресурсов внутри и снаружи меньше вопросов от пользователей (пример: корпоративный веб-портал изнутри и снаружи будет доступен для пользователя по одинаковому адресу WEB.ABC.COM, хотя обслуживающие DNS сервера внутренней и внешней зоны друг о друге не знают);
  • Не нуждается в дополнительной настройке сетевых экранов;
  • Максимальная изоляция пространств имён;

 
Минусы:
  • Для каждого веб-ресурса компании необходимо создать “А” запись в ручную, что не совсем удобно при большом их количестве и частых изменениях;
  • Необходимо отслеживать актуальность записей в DNS, однако при небольшом количестве это несложно.



Разное имя DNS для внутреннего и внешнего пространства имён организации, для разрешения имён используется Conditional Forwarding (Пример: ABC.LOCAL и ABC.COM)

ПРИМЕЧАНИЕ! На сегодняшний день, при построении инфраструктуры использование имён DNS, с неподдерживаемым Интернетом форматом (пример:*.local, *.loc,*.internal), не рекомендуется.
 
В данном сценарии существуют два отдельных DNS сервера для разрешения внутренних и внешних имён. Разрешение внешних веб-ресурсов компании происходит за счёт Conditional Forwarding. К примеру, запрос адреса ресурса WEB.ABC.COM к внутреннему DNS серверу будет перенаправлен на внешний DNS сервер отвечающий за зону ABC.COM. Внешний DNS служит для обслуживания внутренних и внешних пользователей, динамические обновления записей на нём запрещены. Передача зон отключена.

 
Плюсы:
  • Простота администрирования веб-ресурсов компании (достаточно создать новуюА” запись для ресурса на внешнем DNS и он станет доступен внутренним пользователям, а так же пользователям из интернет);
  • Снижение административной нагрузки - нет необходимости отслеживать актуальность “А” записей для внешних веб-ресурсов компании;
 
Минусы:
  • Потребуется конфигурировать сетевые экраны компании для разрешения имён веб-ресурсов из внутренней сети;
  • Могут возникнуть вопросы у пользователей, придётся объяснять разницу между abc.local и abc.com;
  • В случае с настройкой Conditional Forwarding создаётся жесткая привязка имени внешнего домена ABC.COM к IP адресу внешнего DNS, в случае смены IP адреса внешнего DNS не забудьте поменять настройки Conditional Forwarding;

 
Делегированное имя зоны DNS для внутреннего пространства имён DNS (Пример: AD.ABC.COM и ABC.COM)

 
В данном сценарии существует внешний DNS, ответственный за домен ABC.COM, который делегировал внутреннему DNS серверу право на управление внутренней зоной AD.ABC.COM.

 
Плюсы и минусы данного сценария очень напоминают второй случай, однако в данном сценарии нам необходимо предотвратить разрешение имён из зоны AD.ABC.COM запросом снаружи, для этого потребуется сконфигурировать сетевые экраны компании на блокирование такого вида трафика (DNS запроса). Ещё один из возможных плюсов: внешний DNS сервер может являться *nix BIND DNS.

 
 
Сменить IP внешнего DNS будет достаточно проблемно рекомендуется избегать подобных ситуаций.

 
Разрешение же имён веб-ресурсов компании внутренними пользователями происходит за счёт Conditional Forwarding,внешний DNS служит для обслуживания внутренних и внешних пользователей, динамические обновления записей на нём запрещены. Передача зон отключена.

 
Пожалуй, это основные сценарии реализации Split-Brain DNS, надеюсь данная короткая статья позволит вам выбрать правильную архитектуру DNS.

 

 

 

Проблема введения доменного контроллера на базе Windows Server 2008 R2 SP1 в домен Windows Server 2003 R2


ВНИМАНИЕ!: Информация приведённая в данной статье должна восприниматься “как есть”, без каких либо гарантий работоспособности доменных контроллеров, после воспроизведения действий, описанных в статье, со стороны автора. Данная статья является отражением единичного случая, описанного на http://social.technet.microsoft.com/Forums/ru-RU/ws2008r2ru/thread/6b38b1bd-cbed-4856-bb66-e649bd3ec531.

Возможно данная информация кому нибудь поможет.


Описание проблемы:

Корневой доменный контроллер инфраструктуры развёрнут на Windows Server 2003 R2 SP2 x86, на нём размещаются все роли FSMO; При введении в домен доменного контроллера на базе Windows Server 2008 R2 оканчивается ошибкой репликации раздела CN=Configuration;

В журналах присутствуют следующие ошибки:


Имя журнала: Directory Service

Источник: Microsoft-Windows-ActiveDirectory_DomainService

Дата: 10.11.2011 13:06:15

Код события: 1084

Категория задачи:Репликация

Уровень: Ошибка

Ключевые слова:Классический

Пользователь: АНОНИМНЫЙ ВХОД

Компьютер: dc04.msft.local

Описание:

Internal event: Active Directory Domain Services could not update the following object with changes received from the following source directory service. This is because an error occurred during the application of the changes to Active Directory Domain Services on the directory service.

Object:

CN=Configuration,DC=msft,DC=local

Object GUID:

8686a414-5d23-407e-8061-a7d443382eef

Source directory service:

dc01.msft.local

Synchronization of the directory service with the source directory service is blocked until this update problem is corrected.

This operation will be tried again at the next scheduled replication.

User Action

Restart the local computer if this condition appears to be related to low system resources (for example, low physical or virtual memory).

Additional Data

Error value:

8451 Произошла ошибка базы данных при выполнении репликации.

Xml события:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

<System>

<Provider Name="Microsoft-Windows-ActiveDirectory_DomainService" Guid="{0e8478c5-3605-4e8c-8497-1e730c959516}" EventSourceName="NTDS General" />

<EventID Qualifiers="49152">1084</EventID>

<Version>0</Version>

<Level>2</Level>

<Task>5</Task>

<Opcode>0</Opcode>

<Keywords>0x8080000000000000</Keywords>

<TimeCreated SystemTime="2011-11-10T09:06:15.429679800Z" />

<EventRecordID>2009</EventRecordID>

<Correlation />

<Execution ProcessID="452" ThreadID="768" />

<Channel>Directory Service</Channel>

<Computer>dc04.msft.local</Computer>

<Security UserID="S-1-5-7" />

</System>

<EventData>

<Data>CN=Configuration,DC=msft,DC=local</Data>

<Data>8686a414-5d23-407e-8061-a7d443382eef</Data>

<Data>dc01.msft.local</Data>

<Data>Произошла ошибка базы данных при выполнении репликации.</Data>

<Data>8451</Data>

</EventData>

< /Event>



Имя журнала: Directory Service

Источник: Microsoft-Windows-ActiveDirectory_DomainService

Дата: 10.11.2011 13:06:15

Код события: 2108

Категория задачи:Репликация

Уровень: Ошибка

Ключевые слова:Классический

Пользователь: АНОНИМНЫЙ ВХОД

Компьютер: dc04.msft.local

Описание:

В этом событии содержится описание ПРОЦЕДУР ВОССТАНОВЛЕНИЯ для события 1084, которое было записано в журнал событий ранее. Это сообщение указывает на конкретную проблему согласованности базы данных доменных служб Active Directory на этом направлении репликации. Ошибка обработки базы данных произошла при применении реплицированных изменений для следующего объекта. База данных находится в непредвиденном состоянии, не позволяющем внести эти изменения.

Объект:

CN=Configuration,DC=msft,DC=local

GUID объекта:

8686a414-5d23-407e-8061-a7d443382eef

Исходный контроллер домена:

dc01.msft.local

Действия пользователя

Ознакомьтесь со статьей базы знаний 837932, http://support.microsoft.com/?id=837932. Подмножество процедур восстановления приведено ниже.

1. Убедитесь, что на дисках, несущих базу данных доменных служб Active Directory, достаточно свободного места, затем повторите операцию. Убедитесь, что на дисках, несущих NTDS.DIT и файлы журналов, не включено сжатие NTFS. Проверьте, не используется ли для этих дисков антивирусное программное обеспечение.

2. Может быть полезным выполнить принудительное построение родительской цепочки контейнеров этого объекта в базе данных с помощью Security Descriptor Propagator. Это можно сделать, следуя инструкциям из статьи базы знаний 251343, http://support.microsoft.com/?id=251343.

3. Проблема может быть связана с родительским объектом на этом контроллере домена. На исходном контроллере домена переместите этот объект так, чтобы он имел другого родителя.

4. Если этот компьютер является глобальным каталогом и ошибка возникает в одном из разделов, предназначенных только для чтения, то следует лишить этот компьютер роли глобального каталога, сняв флажок глобального каталога в пользовательском интерфейсе "Сайты и службы". Если ошибка происходит в разделе каталога приложений, можно остановить несение раздела каталога приложений на этой реплике. Это можно сделать с помощью команды NTDSUTIL.EXE.

5. Получите самую последнюю версию NTDSUTIL.EXE, установив последний пакет обновления для данной операционной системы. Прежде чем выполнять загрузку в режиме восстановления службы каталогов (DSRM), убедитесь, что вам известен пароль режима DSRM. В противном случае следует сбросить пароль перед перезагрузкой системы.

6. В режиме DSRM запустите командную строку, затем выполните команду "ntdsutil files integrity". Если будет найдено повреждение и существуют другие реплики, лишите эту реплику ее роли и проверьте надежность работы оборудования. Если другие реплики отсутствуют, восстановите состояние системы с помощью архивной копии и повторите эту проверку.

7. Находясь в автономном режиме, выполните дефрагментацию с помощью функции "ntdsutil files compact".

8. Следует также выполнить команду "ntdsutil semantic database analysis". Если будут найдены ошибки, их можно исправить с помощью функции "go fixup". Не путайте эту команду с функцией "ESE repair", которую нельзя использовать в данном случае, поскольку она может привести к потере данных в базе данных Active Directory.

Если ни одно из этих действий не помогает и ошибки репликации продолжаются, следует лишить этот компьютер роли контроллера домена, а затем вновь выдвинуть его на эту роль.

Дополнительные данные

Основная ошибка:

8451 Произошла ошибка базы данных при выполнении репликации.

Вторичная ошибка:

-1507 JET_errColumnNotFound, No such column

Xml события:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

<System>

<Provider Name="Microsoft-Windows-ActiveDirectory_DomainService" Guid="{0e8478c5-3605-4e8c-8497-1e730c959516}" EventSourceName="NTDS General" />

<EventID Qualifiers="49152">2108</EventID>

<Version>0</Version>

<Level>2</Level>

<Task>5</Task>

<Opcode>0</Opcode>

<Keywords>0x8080000000000000</Keywords>

<TimeCreated SystemTime="2011-11-10T09:06:15.429679800Z" />

<EventRecordID>2010</EventRecordID>

<Correlation />

<Execution ProcessID="452" ThreadID="768" />

<Channel>Directory Service</Channel>

<Computer>dc04.msft.local</Computer>

<Security UserID="S-1-5-7" />

</System>

<EventData>

<Data>CN=Configuration,DC=msft,DC=local</Data>

<Data>8686a414-5d23-407e-8061-a7d443382eef</Data>

<Data>dc01.msft.local</Data>

<Data>Произошла ошибка базы данных при выполнении репликации.</Data>

<Data>8451</Data>

<Data>JET_errColumnNotFound, No such column</Data>

<Data>-1507</Data>

</EventData>

< /Event>



Имя журнала: Directory Service

Источник: Microsoft-Windows-ActiveDirectory_DomainService

Дата: 10.11.2011 13:06:15

Код события: 1173

Категория задачи: Внутренняя обработка

Уровень: Предупреждение

Ключевые слова: Классический

Пользователь: АНОНИМНЫЙ ВХОД

Компьютер: dc04.msft.local

Описание:

Internal event: Active Directory Domain Services has encountered the following exception and associated parameters.

Exception:

e0010002

Parameter:

0

Additional Data

Error value:

8451

Internal ID:

106027e

Xml события:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

<System>

<Provider Name="Microsoft-Windows-ActiveDirectory_DomainService" Guid="{0e8478c5-3605-4e8c-8497-1e730c959516}" EventSourceName="NTDS General" />

<EventID Qualifiers="32768">1173</EventID>

<Version>0</Version>

<Level>3</Level>

<Task>9</Task>

<Opcode>0</Opcode>

<Keywords>0x8080000000000000</Keywords>

<TimeCreated SystemTime="2011-11-10T09:06:15.429679800Z" />

<EventRecordID>2011</EventRecordID>

<Correlation />

<Execution ProcessID="452" ThreadID="768" />

<Channel>Directory Service</Channel>

<Computer>dc04.msft.local</Computer>

<Security UserID="S-1-5-7" />

</System>

<EventData>

<Data>e0010002</Data>

<Data>8451</Data>

<Data>0</Data>

<Data>106027e</Data>

</EventData>

< /Event>



Анамнез:

Уровень леса и домена Windows Server 2003;

Подготовка к введению в инфраструктуру доменного контроллера на базе Windows Server 2008 R2 SP1 прошла успешно:

Подготовка леса и домена с помощью adprep /forest prep и adprep /domainprep /gpprep выполнена без ошибок;

Значение ObjectVertion после выполнения adprep для контейнера Schema:

CN=Schema, CN=Configuration, DC=MSFT, DC=LOCAL равно 47 http://bshwjt.blogspot.com/2010/07/schema-version.html

Значение Revision после выполнения adprep для контейнера ActiveDirecrotyUpdate:

CN=ActiveDirectoryUpdate, CN=ForestUpdates, CN=Configuration, DC=MSFT, DC=LOCAL равно 5 http://technet.microsoft.com/en-us/library/dd378805(WS.10).aspx;

DCdiag ошибок в функционировании доменного контроллера не выявляет;

Стандартные решения, которые предлагались в рамках инцидента http://social.technet.microsoft.com/Forums/ru-RU/ws2008r2ru/thread/6b38b1bd-cbed-4856-bb66-e649bd3ec531 не приводили к результату;

Вероятная причина:

Доподлинно установить не удалось, но есть подозрение, что вызвано некорректной работой adprep x86;

Решение:

В ручную через ADSI были изменены значения:

CN=Schema, CN=Configuration, DC=MSFT, DC=LOCAL равно 44

CN=ActiveDirectoryUpdate, CN=ForestUpdates, CN=Configuration, DC=MSFT, DC=LOCAL равно 2

После этого было проведено повторное расширение схемы и подготовка домена для Windows Server 2008 R2.

Доменные контроллеры успешно ввелись в домен, репликация прошла успешно.

Благодарности:

Спасибо Smirnov_Nik за возможность совместно найти решение данного вопроса.

Коллеги, если у кого была похожая проблема поделитесь опытом!