- Remove From My Forums
-
Question
-
Hi all,
Previously my original issue was with WSUS settings set in GPO not applying correctly which apparently is caused by problems with GPO. In the gpresult file, under
Computer Details, it simply says No data available.There are also these two error messages found in User Details — Settings — Administrative Templates
The following errors were encountered:
An appropriate resource file could not be found for file \CompanyName.COM.MYsysvolCompanyName.COM.MYPoliciesPolicyDefinitions3.admx (error = 2): The system cannot find the file specified.
Namespace ‘Microsoft.Policies.WindowsStore’ is already defined as the target namespace for another file in the store. File \CompanyName.COM.MYsysvolCompanyName.COM.MYPoliciesPolicyDefinitionswinstoreui.admx, line 4, column 80What should I do to troubleshoot and fix these problems?
Thanks in advance
mac
Answers
-
Hi all,
The problems have all been solved.
— No data available — Used an elevated prompt to run gpresult. A full report was successfully generated.
— Settings not applying — This was caused by two GPOs conflicting with each other. The settings in the winning GPO is the wrong setting.
— Namespace error message — Conflicting templates for Windows Store. I removed both of them because we don’t use them. No more error message.
— Missing admx file — Actually, it’s a missing adml file. Have removed the problem admx file because we don’t need it anymore. It contained some specific settings for Windows XP, which were phased out earlier this year.
Thank you all for replying.
-
Proposed as answer by
Wednesday, October 18, 2017 8:28 AM
-
Marked as answer by
macdyne73
Wednesday, October 18, 2017 8:38 AM -
Edited by
macdyne73
Wednesday, October 18, 2017 8:40 AM
Grammar
-
Proposed as answer by
Обычно объекты групповой политики назначаются на контейнер (домен, сайт или OU) и применяются ко всем объектам в этом контейнере. При грамотно организованной структуре домена этого вполне достаточно, однако иногда требуется дополнительно ограничить применение политик определенной группой объектов. Для этого можно использовать два типа фильтров.
Фильтры безопасности
Фильтры безопасности позволяют ограничить применение политик определенной группой безопасности. Для примера возьмем GPO2, с помощью которого производится централизованная настройка меню Пуск на рабочих станциях с Windows 8.1Windows 10. GPO2 назначен на OU Employees и применяется ко всем без исключения пользователям.
Теперь перейдем на вкладку «Scope», где в разделе «Security Filtering» указаны группы, к которым может быть применен данный GPO. По умолчанию здесь указывается группа Authenticated Users. Это означает, что политика может быть применена к любому пользователю или компьютеру, успешно прошедшему аутентификацию в домене.
На самом деле каждый GPO имеет свой список доступа, который можно увидеть на вкладке «Delegation».
Для применения политики объект должен иметь права на ее чтение (Read) и применение (Apply group policy), которые и есть у группы Authenticated Users. Соответственно для того, чтобы политика применялась не ко всем, а только к определенной группе, необходимо удалить из списка Authenticated Users, затем добавить нужную группу и выдать ей соответствующие права.
Так в нашем примере политика может применяться только к группе Accounting.
WMI фильтры
Windows Management Instrumentation (WMI) — один из наиболее мощных инструментов для управления операционной системой Windows. WMI содержит огромное количество классов, с помощью которых можно описать практически любые параметры пользователя и компьютера. Посмотреть все имеющиеся классы WMI в виде списка можно с помощью PowerShell, выполнив команду:
Get-WmiObject -List
Для примера возьмем класс Win32_OperatingSystem, который отвечает за свойства операционной системы. Предположим, что требуется отфильтровать все операционные системы кроме Windows 10. Заходим на компьютер с установленной Window 10, открываем консоль PowerShell и выводим имя, версию и тип операционной системы с помощью команды:
Get-WmiObject -Class Win32_OperatingSystem | fl Name, Version, ProductType
Для фильтра используем версию и тип ОС. Версия одинакова для клиентских и серверных ОС и определяется так:
• Window Server 2016Windows 10 — 10.0
• Window Server 2012 R2Windows 8.1 — 6.3
• Window Server 2012Windows 8 — 6.2
• Window Server 2008 R2Windows 7 — 6.1
• Window Server 2008Windows Vista — 6.0
Тип продукта отвечает за назначение компьютера и может иметь 3 значения:
• 1 — рабочая станция;
• 2 — контроллер домена;
• 3 — сервер.
Теперь переходим непосредственно к созданию фильтра. Для этого открываем оснастку «Group Policy Management» и переходим к разделу «WMI Filters». Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «New».
В открывшемся окне даем фильтру имя и описание. Затем жмем кнопку «Add» и поле «Query» вводим WQL запрос, который и является основой WMI фильтра. Нам необходимо отобрать ОС версии 10.0 с типом 1, соответственно запрос будет выглядеть так:
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE ″10.0%″ AND ProductType = ″1″
Примечание. Windows Query Language (WQL) — язык запросов WMI. Подробнее о нем можно узнать на MSDN.
Сохраняем получившийся фильтр.
Теперь осталось только назначить WMI фильтр на объект групповой политики, например на GPO3. Переходим к свойствам GPO, открываем вкладку «Scope» и в поле «WMI Filtering» выбираем из списка нужный фильтр.
Анализ применения групповых политик
При таком количестве способов фильтрации GPO необходимо иметь возможность диагностики и анализа их применения. Проще всего проверить действие групповых политик на компьютере можно с помощью утилиты командной строки gpresult.
Для примера зайдем на компьютер wks2, на котором установлена ОС Windows 7, и проверим, сработал ли WMI фильтр. Для этого открываем консоль cmd с правами администратора и выполняем команду gpresult /r, которая выводит суммарную информацию о групповых политиках, примененных к пользователю и компьютеру.
Примечание. Утилита gpresult имеет множество настроек, посмотреть которые можно командой gpresult /?.
Как видно из полученных данных, к компьютеру не применилась политика GPO3, поскольку она была отфильтрована с помощью фильтра WMI.
Также проверить действие GPO можно из оснастки «Group Policy Management», с помощью специального мастера. Для запуска мастера кликаем правой клавишей мыши на разделе «Group Policy Results» и в открывшемся меню выбираем пункт «Group Policy Results Wizard».
Указываем имя компьютера, для которого будет составлен отчет. Если требуется просмотреть только пользовательские настройки групповой политики, то настройки для компьютера можно не собирать. Для этого необходимо поставить галочку снизу (display user policy settings only).
Затем выбираем имя пользователя, для которого будут собираться данные, либо можно указать не включать в отчет настройки групповой политики для пользователя (display computer policy settings only).
Проверяем выбранные настройки, жмем «Next» и ждем, пока собираются данные и генерируется отчет.
Отчет содержит исчерпывающие данные об объектах групповых политик, примененных (или не примененных) к пользователю и компьютеру, а также об используемых фильтрах.
Для примера составим отчеты для двух разных пользователей и сравним их. Первым откроем отчет для пользователя Kirill и перейдем в раздел настроек пользователя. Как видите, к этому пользователю не применилась политика GPO2, поскольку у него нет прав на ее применение (Reason Denied — Inaсcessible).
А теперь откроем отчет для пользователя Oleg. Этот пользователь является членом группы Accounting, поэтому к нему политика была успешно применена. Это означает, что фильтр безопасности успешно отработал.
На этом, пожалуй, я закончу ″увлекательное″ повествование о применении групповых политик. Надеюсь эта информация будет полезной и поможет вам в нелегком деле системного администрирования 🙂
- Remove From My Forums
-
Общие обсуждения
-
Здравствуйте!
Проблема возникла с Active Directory на Windows Server 2008 R2:Поднят тестовый контроллер домена personal.company.com, заведено несколько пользователей Administarator — хозяин домена, admin — Администратор домена и user — пользователь домена. Есть рабочая станция на Windows XP SP2, заведена в домен. Создана групповая политика,
связанная с доменом personal.company.com, но эта политика не применяется к клиентам, на сервере все применяется, как к пользователям, так и к компьютерам.Грубо говоря, пользователю запрещено редактировать реестр (к примеру), но заходя на Xp в домен personal, пользователь admin/user имеет возможность не только открыть реестр, но и редактировать его.
Команда gpupdate /force (и без ключа и с ключами /boot, /logoff) применялась как на контроллере, так и на самой станции, не помогает
Результаты команды gpresult на Xp (пол-ли user, admin, administartor): Пользователь «…» не имеет данных RSOP (драйвера на сетевую скачивала с сайта производителя)
Ожидание инициализации при загрузке Включено
Sid компьютера меняла несколько раз (при этом выводила из домена, меняла и заводила обратно в домен), даже Xp переустонавливала и в домен заводила на стадии установки Xp, но ничего не помогает. В интернете уже по несколько раз читала и пробовала все, что
советовали, но ничего не помогает. Ощущение, будто XP применяет свои локальные политики, а до домена ей по барабану. Уже не знаю, куда и копать и где проблема. Буду очень признательна, если вы мне поможете-
Изменен тип
5 мая 2011 г. 6:05
давность и отсутствие активности в теме
-
Изменен тип
- Remove From My Forums
-
Question
-
In Group Policy Manager when a WMI filter is created an error message is displayed:
Either the namespace entered is not a valid namespace on the local computer or you do not have access to this namespace on this computer. It is possible this is a valid namespace on the remote computer)s). If you wish to use this namespace, press
OK. Press cancel to choose another namespace.I am signed on as the domain administrator. This domain is Server 2012 R2.
The namespace is the common rootcimv2. When the browse button is pressed many namespaces are listed. The error occurs no mater what namespace is selected.
Even if the error message is ignored and the wmi filter is created. For windows 8 clients, wmi filters fail even though they should pass.
Select * from win32_operatingsystem where version like «6.%» will evaluate to false.
This is happening on two Server 2012 R2 domains.
Has anyone seen this? Is there a fix?
-
Moved by
Tuesday, February 25, 2014 6:34 AM
move to more related
-
Moved by
Answers
-
Well Microsoft technical support after a few hours got it to work.
It turns out that you need to enclose the where clause in parentheses!!
The following Query will actually work:
Select * from WIN32_OperatingSystem where ((Version > «6») and (ProductType = 1))
I really think this is a bug, since the parentheses should not be needed.
-
Marked as answer by
dga_1
Wednesday, March 5, 2014 5:07 PM
-
Marked as answer by
- Remove From My Forums
-
Общие обсуждения
-
Здравствуйте!
Проблема возникла с Active Directory на Windows Server 2008 R2:Поднят тестовый контроллер домена personal.company.com, заведено несколько пользователей Administarator — хозяин домена, admin — Администратор домена и user — пользователь домена. Есть рабочая станция на Windows XP SP2, заведена в домен. Создана групповая политика,
связанная с доменом personal.company.com, но эта политика не применяется к клиентам, на сервере все применяется, как к пользователям, так и к компьютерам.Грубо говоря, пользователю запрещено редактировать реестр (к примеру), но заходя на Xp в домен personal, пользователь admin/user имеет возможность не только открыть реестр, но и редактировать его.
Команда gpupdate /force (и без ключа и с ключами /boot, /logoff) применялась как на контроллере, так и на самой станции, не помогает
Результаты команды gpresult на Xp (пол-ли user, admin, administartor): Пользователь «…» не имеет данных RSOP (драйвера на сетевую скачивала с сайта производителя)
Ожидание инициализации при загрузке Включено
Sid компьютера меняла несколько раз (при этом выводила из домена, меняла и заводила обратно в домен), даже Xp переустонавливала и в домен заводила на стадии установки Xp, но ничего не помогает. В интернете уже по несколько раз читала и пробовала все, что
советовали, но ничего не помогает. Ощущение, будто XP применяет свои локальные политики, а до домена ей по барабану. Уже не знаю, куда и копать и где проблема. Буду очень признательна, если вы мне поможете-
Изменен тип
5 мая 2011 г. 6:05
давность и отсутствие активности в теме
-
Изменен тип
Обычно объекты групповой политики назначаются на контейнер (домен, сайт или OU) и применяются ко всем объектам в этом контейнере. При грамотно организованной структуре домена этого вполне достаточно, однако иногда требуется дополнительно ограничить применение политик определенной группой объектов. Для этого можно использовать два типа фильтров.
Фильтры безопасности
Фильтры безопасности позволяют ограничить применение политик определенной группой безопасности. Для примера возьмем GPO2, с помощью которого производится централизованная настройка меню Пуск на рабочих станциях с Windows 8.1Windows 10. GPO2 назначен на OU Employees и применяется ко всем без исключения пользователям.
Теперь перейдем на вкладку «Scope», где в разделе «Security Filtering» указаны группы, к которым может быть применен данный GPO. По умолчанию здесь указывается группа Authenticated Users. Это означает, что политика может быть применена к любому пользователю или компьютеру, успешно прошедшему аутентификацию в домене.
На самом деле каждый GPO имеет свой список доступа, который можно увидеть на вкладке «Delegation».
Для применения политики объект должен иметь права на ее чтение (Read) и применение (Apply group policy), которые и есть у группы Authenticated Users. Соответственно для того, чтобы политика применялась не ко всем, а только к определенной группе, необходимо удалить из списка Authenticated Users, затем добавить нужную группу и выдать ей соответствующие права.
Так в нашем примере политика может применяться только к группе Accounting.
WMI фильтры
Windows Management Instrumentation (WMI) — один из наиболее мощных инструментов для управления операционной системой Windows. WMI содержит огромное количество классов, с помощью которых можно описать практически любые параметры пользователя и компьютера. Посмотреть все имеющиеся классы WMI в виде списка можно с помощью PowerShell, выполнив команду:
Get-WmiObject -List
Для примера возьмем класс Win32_OperatingSystem, который отвечает за свойства операционной системы. Предположим, что требуется отфильтровать все операционные системы кроме Windows 10. Заходим на компьютер с установленной Window 10, открываем консоль PowerShell и выводим имя, версию и тип операционной системы с помощью команды:
Get-WmiObject -Class Win32_OperatingSystem | fl Name, Version, ProductType
Для фильтра используем версию и тип ОС. Версия одинакова для клиентских и серверных ОС и определяется так:
• Window Server 2016Windows 10 — 10.0
• Window Server 2012 R2Windows 8.1 — 6.3
• Window Server 2012Windows 8 — 6.2
• Window Server 2008 R2Windows 7 — 6.1
• Window Server 2008Windows Vista — 6.0
Тип продукта отвечает за назначение компьютера и может иметь 3 значения:
• 1 — рабочая станция;
• 2 — контроллер домена;
• 3 — сервер.
Теперь переходим непосредственно к созданию фильтра. Для этого открываем оснастку «Group Policy Management» и переходим к разделу «WMI Filters». Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «New».
В открывшемся окне даем фильтру имя и описание. Затем жмем кнопку «Add» и поле «Query» вводим WQL запрос, который и является основой WMI фильтра. Нам необходимо отобрать ОС версии 10.0 с типом 1, соответственно запрос будет выглядеть так:
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE ″10.0%″ AND ProductType = ″1″
Примечание. Windows Query Language (WQL) — язык запросов WMI. Подробнее о нем можно узнать на MSDN.
Сохраняем получившийся фильтр.
Теперь осталось только назначить WMI фильтр на объект групповой политики, например на GPO3. Переходим к свойствам GPO, открываем вкладку «Scope» и в поле «WMI Filtering» выбираем из списка нужный фильтр.
Анализ применения групповых политик
При таком количестве способов фильтрации GPO необходимо иметь возможность диагностики и анализа их применения. Проще всего проверить действие групповых политик на компьютере можно с помощью утилиты командной строки gpresult.
Для примера зайдем на компьютер wks2, на котором установлена ОС Windows 7, и проверим, сработал ли WMI фильтр. Для этого открываем консоль cmd с правами администратора и выполняем команду gpresult /r, которая выводит суммарную информацию о групповых политиках, примененных к пользователю и компьютеру.
Примечание. Утилита gpresult имеет множество настроек, посмотреть которые можно командой gpresult /?.
Как видно из полученных данных, к компьютеру не применилась политика GPO3, поскольку она была отфильтрована с помощью фильтра WMI.
Также проверить действие GPO можно из оснастки «Group Policy Management», с помощью специального мастера. Для запуска мастера кликаем правой клавишей мыши на разделе «Group Policy Results» и в открывшемся меню выбираем пункт «Group Policy Results Wizard».
Указываем имя компьютера, для которого будет составлен отчет. Если требуется просмотреть только пользовательские настройки групповой политики, то настройки для компьютера можно не собирать. Для этого необходимо поставить галочку снизу (display user policy settings only).
Затем выбираем имя пользователя, для которого будут собираться данные, либо можно указать не включать в отчет настройки групповой политики для пользователя (display computer policy settings only).
Проверяем выбранные настройки, жмем «Next» и ждем, пока собираются данные и генерируется отчет.
Отчет содержит исчерпывающие данные об объектах групповых политик, примененных (или не примененных) к пользователю и компьютеру, а также об используемых фильтрах.
Для примера составим отчеты для двух разных пользователей и сравним их. Первым откроем отчет для пользователя Kirill и перейдем в раздел настроек пользователя. Как видите, к этому пользователю не применилась политика GPO2, поскольку у него нет прав на ее применение (Reason Denied — Inaсcessible).
А теперь откроем отчет для пользователя Oleg. Этот пользователь является членом группы Accounting, поэтому к нему политика была успешно применена. Это означает, что фильтр безопасности успешно отработал.
На этом, пожалуй, я закончу ″увлекательное″ повествование о применении групповых политик. Надеюсь эта информация будет полезной и поможет вам в нелегком деле системного администрирования 🙂
Обновлено 10.07.2019
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов России Pyatilistnik.org. В прошлый раз мы решили ошибку в Active Directory, когда мы видели сообщение, что «База данных диспетчера учетных записей на сервере не содержит записи», двигаемся дальше. В данной публикации мы рассмотрим ошибку при открытии административных шаблонов в объекте групповой политики, а именно «Пространство имен уже определено как целевое пространство имен«. При открытии GPO так же выскакивает ошибка, давайте разбираться откуда растут ноги.
В моем домене Active Directory есть контроллер домена работающий на Windows Server 2012 R2, на нем я развернул центральное хранилище административных шаблонов групповой политики. После того, как я наполнил мое центральное хранилище свежими ADMX шаблонами, я попытался отредактировать политику по увеличению размера токена Kerberos, но в итоге я получил вот такое предупреждение:
Ошибка при сборе данных для «Административные шаблоны». Пространство имен «Microsoft.Policies.WindowsStore» уже определено как целевое пространство имен для другого файла в хранилище. Файл dc01.root.pyatilistnik.orgSysVolroot.pyatilistnik.orgPolicePolicyDefenitionsWinStoreUI.admx, строка 4 столбец 80
При попытке открыть объект групповой политики, так же выскакивало окно.
А вот то же самое в английском варианте:
File dc01.root.pyatilistnik.orgSysVolroot.pyatilistnik.orgPolicePolicyDefenitionsWinStoreUI.admx, line 4, column 80
При обновлении центрального хранилища ADMX для Windows 10 v1511 я обнаружил данную ошибку. По всей видимости, Microsoft снова изменила имя шаблона ADMX с Windows 10 на Windows 10 v1511. WinStoreUI.admx был переименован в WindowsStore.admx.
Методы решения
- Способ — Вы можете проигнорировать ошибку, нажав OK, но меня такое окно постоянно выскакивающее при любом редактировании GPO дико бесил, поэтому это не мой вариант.
- 2 Способ:
- Удалите WinStoreUI.admx и WinStoreUI.adml (в языковой папке, например «en-us»)
- Переименуйте WindowsStore.admx в WinStoreUI.admx
- Переименуйте WindowsStore.adml в WinStoreUI.adml
Различия между этими двумя файлами в этот раз также ощутимы: изменения в поддерживаемой строке, а также в строках, описывающих отключение параметров обновления ОС для пользователей и компьютеров. По этой причине важно получить более новый файл, в то время как переименование файлов позволяет сохранить все старые настройки. Если вы не использовали предыдущие настройки, вы можете решить проблему только с помощью шага 1 второго метода.
Следуя 2 способу, вы сможете редактировать групповые политики без предупреждения о пространстве имен. Вы можете найти параметры магазина в разделе «Конфигурация компьютера» и «Конфигурация пользователя» в PoliciesWindows ComponentsStore. Как видим все получилось. Это еще один повод всегда держать свежие файлы ADMX. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org,
Справка Google
- Справочный центр
- Сообщество
- Search Console
- Политика конфиденциальности
- Условия предоставления услуг
- Отправить отзыв
Тема отзыва
Информация в текущем разделе Справочного центра
Общие впечатления о Справочном центре Google
- Справочный центр
- Сообщество
Search Console
Обновлено 28.06.2022
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами подробно разобрали сетевую технологию VLAN и ее применение. В сегодняшней статье я расскажу, как решил вот такую ситуацию на одном из терминальных столов. Нужно мне было проверить применение групповых политик для пользователя, в момент диагностики я, как обычно попытался воспользоваться утилитой GPresult, но в итоге получил ошибку «Пользователь не имеет данных RSOP«. Давайте разбираться в чем дело.
Я первый раз получил такую ошибку в своей практике. Мое окружение, это RDS хост с Windows Server 2012 R2. Командная строка работает в режиме администратора. Напоминаю, что GPresult — это утилита показывающая подробный отчет по примененным или отклоненным групповым политикам пользователя и компьютера, чтобы системный администратор имел представление и знал, где диагностировать проблему. Вот так вот выглядит ошибка «gpresult /r Пользователь не имеет данных RSOP (The user does not have RSoP data)»
Я подумал, ладно пойду другим путем и попробую проверить применение политик GPO через RSOP, но и тут я получил ошибку:
Не удалось создать данные результирующей политики из-за указанных ниже ошибки. Недостаточно памяти.
Если посмотреть журнал с логами Windows, то вы обнаружите вот такое предупреждение:
Код события 1090: Windows не удалось записать информацию результирующей политики (RSoP), которая описывает область применения объектов групповой политики к этому компьютеру или пользователю. Возможные причины: отключение или остановка службы WMI (инструментария управления Windows), иные ошибки WMI. Параметры групповой политики были успешно применены к этому компьютеру или пользователю, но, возможно, средства управления сообщают неверные данные.
Первым делом проверьте, что у вас в запущенном состоянии служба инструментария управления Windows (Winmgmt). Для этого откройте оболочку PowerShell и введите команду:
Если у вас будет статус «Stop», то введите команду:
Get-Service wmiApSrv | Start-Service
Так же вы можете перезапустить сервис, командой:
Get-Service wmiApSrv | Restart-Service
Следующим шагом я вам советую добавить ключ в реестр Windows. Переходим в ветку:
HKEY_LOCAL_MACHINESOFTWAREPolicies MicrosoftWindowsSystem
Создаем ключ dword32
с именем GroupPolicyMinTransferRate и значением 0
И точно такой же в ветке:
HKEY_CURRENT_USERSoftwarePolicies MicrosoftWindowsSystem
Создаем ключ dword32 с именем GroupPolicyMinTransferRate и значением 0. Перезагружаем компьютер или сервер. Данная манипуляция в большинстве случаев исправляет ошибку GPResult пользователь не имеет данных RSOP.
Если первый метод не помог, то пробуем удалить из реестра всю историю объекта групповой политики из профиля пользователя. Перед удалением обязательно сделайте резервную копию ветки реестра.
HKEY_CURRENT_USERSoftwareMicrosoftWindows CurrentVersionGroup PolicyHistory
После чего в командной строке вводим gpupdate /force, а затем gpresult /h. В итоге ошибка «Пользователь не имеет данных RSOP», должна пропасть. Еще одним методом устранения проблемы в обработке результирующей политики, является вывод компьютера из домена Active Directory, и повторный ввод в домен.
Я наблюдал ошибку «The user does not have RSoP data», когда люди пытались удаленно выполнять команду результирующей политики, для еще не вошедшего в систему пользователя, или наоборот у них командная строка запущена от имени другого пользователя, например с большими правами, но он так же не вошел интерактивно на сервер. Тут два варианта, либо вы заходите под ним на сервер или же в в выводе gpresult вы используете его данные, простой пример:
gpresult /r user:rootbarboskin.g
P.S. Дополнительные решения
- Еще на многих форумах советуют проверить ваши сетевые настройки в частности DNS, правильно ли разрешаются имена контроллеров домена.
- Установите все доступные обновления безопасности и исправления в системе.
Надеюсь мое небольшой опыт окажется вам полезным, а с вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.