Алексей Максимов, Автор в Блог IT-KB

На вторичном сервере DPM (Secondary DPM) в одной из Protection Group, в которую были включены кластеризованные виртуальные машины Hyper-V, для некоторых виртуальных машин перестало работать создание точек восстановления по расписанию. Попытка вручную выполнить Consistency Check приводила к ошибке: An unexpected error occurred while the job was running. (ID 104 Details: The device is not connected (0x8007048F)) Решение было обнаружено здесь: Secondary DPM does not sync with primary (3170 / 8007048F). Смысл его заключается в том, чтобы проверить на первичном сервере DPM наличие логических дисковых томов не имеющих информации о типе файловой системы (RAW тома), и если таковые будут обнаружены, – удалить их. Быстро проверить на первичном сервере DPM (Primary DPM) список томов отобрав только те, у которых нет информации о типе файловой системы можно, например с помощью PowerShell: Get-Volume | Where {$_.FileSystem -eq ""} Если посмотреть в оснастку управления дисками diskmgmt.msc, там мы обнаружим это же количество томов без определения файловой системы, а также сможем увидеть их размер: Чтобы исправить ситуацию, откроем командную строку с правами Администратора и вызовем утилиту DISKPART. Получив приглашение командной строки этой утилиты, чтобы получить список всех логических дисковых томов, выполним команду: list volume Внимательно просмотрим список томов и выпишем номера томов, которые не имеют определения файловой системы. Выписываем себе номера RAW томов (в моём случае было обнаружено 3 таких тома — 78, 138, 143). Далее будем делать эти тома текущими и удалять. Удалять надо снизу вверх, то есть сначала тома с бОльшими номерами, так как после удаления выбранного тома нумерация всех томов сдвигается. Итак, выберем проблемный том с самым большим номером: select volume=143 После того, как утилита сообщить о том, что том успешно выбран, выполняем удаление текущего выбранного тома командой: delete volume Таким образом удаляем все обнаруженные RAW тома. После удаления повторно проверяем наличие проблемных томов любым ранее описанным методом, и если они отсутствуют, снова

В процессе использования прокси-сервера Squid при большом количестве пользователей и относительно небольшой пропускной способности каналов предоставленных интернет-провайдерами может возникнуть потребность ограничить пропускную способность доступа в интернет разным категориям пользователей. Один из основных механизмов позволяющих реализовать такие ограничения в Squid является механизм пулов задержки — Delay pools. Пулы задержки позволяют ограничить скорость получаемого прокси-сервером интернет-трафика в зависимости от разных условий, например в зависимости от того, какой пользователь запрашивает этот трафик. В конфигурации Squid по умолчанию механизм пулов задержки выключен, и поэтому при доступе к прокси-серверу между клиентами используется простая конкуренция по принципу “кто первый встал, того и тапки”. Как примерно я понимаю работу Squid в конфигурации с включёнными пулами задержки: — клиент запрашивает с прокси-сервера какой-либо http-объект;— в случае если запрашиваемый объект есть в кэше Squid (статус TCP_HIT в access.log), то прокси-сервер отдает этот объект клиенту на максимальной скорости— в случае если запрашиваемого объекта нет в кэше (статусы TCP_MISS, TCP_TUNNEL и другие в access.log), то прокси-сервер отдает этот объект клиенту с ограничениями настроенными в пулах задержки. Далее мы рассмотрим простейший пример применения пулов задержки. В рассматриваемом примере будет использоваться три категории пользователей, для каждой из которых будет задано ограничение максимальной скорости интернет: — Первая категория будет определять трудновоспитуемых пользователей, у которых большую часть интернет-трафика можно классифицировать как, мягко говоря, непрофильный. Эта категория будет иметь самую низкую скорость доступа в интернет;— Вторая категория – это стандартные пользователи с ограничением скорости позволяющим выполнять более или менее комфортный интернет-серфинг;— Третья категория – пользователи с повышенной границей пропускной способности в рабочее время и без ограничений в нерабочее время. Для начала убедимся в том, что Squid собран с поддержкой Delay pools squid3 -v Squid Cache: Version 3.5.4 Service Name: squid configure options:... '--enable-delay-pools'... *** Категоризацию пользователей мы будем выполнять на основе групп безопасности в домене Active Directory. Соответственно предварительно нам нужно создать эти группы доступа. К

При установке системных обновлений в виртуальной машине с Ubuntu Server 14.04 32-bit я столкнулся с ситуацией, когда вновь установленное в систему ядро Linux не смогло загрузиться. Если система была установлена с загрузчиком GRUB, то в процессе каждой загрузки у нас есть возможность вручную выбрать ядро (предполагается, что при обновлении мы сохранили старое работоспособное ядро), которое будет загружено. Когда процесс загрузки отобразит меню GRUB, выберем пункт меню Advanced options for Ubuntu В появившемся списке доступных для загрузки ядер Linux выберем предыдущее ядро, с которым загрузка ВМ проходила успешно до обновления (в моём случае это ядро версии 3.13.0.-24). Однако при следующей перезагрузке системы без ручного вмешательства в процесс загрузки, загрузчик GRUB всё-равно запустит более новое ядро, так как оно назначено в качестве ядра по умолчанию. Для того, чтобы переопределить загружаемое по умолчанию ядро, запомним позицию нужного нам ядра в списке GRUB (в моём случае это 2 позиция с учётом того, что нумерация идёт с 0). Загрузим систему, вручную выбрав нужное ядро, и отредактируем конфигурационный файл GRUB: sudo nano /etc/default/grub В файле отредактируем строчку, как описано здесь, указав индекс нужных позиций структуры меню GRUB, чтобы добраться до ядра, которое будет загружаться по умолчанию (первая цифра означает позицию меню первого уровня, вторая – второго уровня соответственно): GRUB_DEFAULT="1>2" Сохраним изменения в файле и обновим информацию в самом загрузчике: sudo update-grub Перезагрузим сервер и убедимся в том, что система успешно запускается c нужным нам ядром: uname -r 3.13.0-24-generic

Несмотря на то, что такой продукт, как App Controller из состава System Center 2012 R2, можно сказать, уже близок к завершению своего жизненного цикла, выполнять его установку и настройку, да ещё и в варианте Hight Availability, мне до сих пор не доводилось. Практика показала, что процедура такого развёртывания имеет свои нюансы, и поэтому в данной заметке я попытаюсь пошагово описать данный процесс. Основным и главным условием развёртывания высоко-доступного App Controller в моём случае будет использование уже имеющихся серверов System Center 2012 R2 Virtual Machine Manager (VMM), то есть установка служб App Controller будет выполняться на узлы действующего кластера VMM, конфигурация которого рассматривалась ранее в заметке Обновляем System Center 2012 SP1 Virtual Machine Manager до уровня System Center 2012 R2 на Windows Server 2012 R2 и SQL Server 2012 SP1 с параллельным переходом в режим Highly Available. Предвосхищая вопрос о целесообразности использования App Controller в то время, как Microsoft предлагает на замену этого продукта более мощный и функциональный Windows Azure Pack, могу сказать то, что в моём случае функционала App Controller более чем достаточно (требуется элементарная раздача прав разным категориям пользователей на управление рядом виртуальных машин из кластера Hyper-V). К тому же меня пока отпугивает некая “монструозность” как самой архитектуры Windows Azure Pack, так и процесса его развёртывания. Для начала напомню о конфигурации ранее описанной среды, в которой мы будем выполнять развёртывание высоко-доступного App Controller. Это две виртуальные машины с именами KOM-AD01-SCVM01 и KOM-AD01-SCVM02 образуют кластерный экземпляр на базе Windows Failover Cluster в составе ОС Windows Server 2012 R2 с именем KOM-AD01-SCVMCL. На эти две виртуальные машины мы и будем устанавливать App Controller с последующим созданием NLB-кластера c именем KOM-AD01-SCACCL на внешнем балансировщике (не забываем о невозможности сосуществования служб Windows Failover Cluster и Windows NLB в рамках одной серверной ОС Windows Server). При этом оба установленных экземпляра App Controller будут использовать

Иногда возникают ситуации, когда по части символической ссылки ведущей к логическим дискам используемым для хранения бэкапа в DPM необходимо определить то, к какой конкретной группе защиты относится такая ссылка. Например, недавно я получил от SCOM предупреждение о необходимости просканировать файловую систему на предмет ошибок на одном из таких дисков, из содержимого которого понять то, о какой группе защиты идёт речь, не удалось. Alert: Windows Server 2012 NTFS File System Corrupt Source: C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_298ef3dd-b90c-4b6d-9463-046d30ddd497 Path: KOM-AD01-SCDPM1.holding.com Description: The Drive C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_298ef3dd-b90c-4b6d-9463-046d30ddd497 of the Device Named as \Device\HarddiskVolume31 reports a Corruption Action State of 1. Resolution state: New... В таких случаях на сервере DPM можно запустить консоль DPM Management Shell и получить полную информацию о всех источниках защиты, в том числе и о логических дисках, на которых хранятся данные реплики: Get-DPMDataSource | fl -Property * Однако если источников защиты много, то вывод может получиться очень объёмным, поэтому чтобы получить только нужную нам информацию, можно выполнить PS-скрипт с точным указанием части интересующего нас пути (это значение записано в переменную $FindPath) $FindPath = "vol_298ef3dd-b90c-4b6d-9463-046d30ddd497" $AllDS = Get-DPMDataSource ForEach ($DS in $AllDS) { $Paths = $DS.ProtectableObjectLoadPath ForEach ($Path in $Paths) { $Array = $Path.GetEnumerator() ForEach ($Item in $Array) { If ($Item.Value -match $FindPath) { Write-Host $Item.Key " --> " $Item.Value } } } } Вывод скрипта будет выглядеть примерно следующим образом… D:\ on kom-ts01-app01.holding.com --> c:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_298ef3dd-b90c-4b6d-9463-046d30ddd497\b73f7188-6cb2-4 cdf-a70e-dad9b1056689\Full\ Это позволит идентифицировать соответствующую группу защиты:

Ранее мы уже рассматривали пример модификации навигационной панели Suite Bar в SharePoint 2013, задавая с помощью PowerShell значение свойства SuiteBarBrandingElementHtml для конкретного веб-приложения. На этот раз задача немного усложнилась и нам потребовалось вместо плоской одноуровневой структуры ссылок организовать много-уровневое меню. Интересная реализация такой задачи была найдена в статье Ashok Raja’s Blog — Create a Multilevel Hierarchical Menu in SharePoint 2013 with SuiteBar Branding Delegate Control. Чтобы не заморачиваться со сборкой и установкой солюшна с последующим созданием списков, отвечающих за структуру будущего меню для каждого семейства сайтов, из решения была позаимствована сама идея и код формирования многоуровневого меню средствами CSS. Так как значение свойства SuiteBarBrandingElementHtml содержит по сути своей HTML-код, то всё, что нам потребовалось сделать для решения задачи, это сформировать код, приправив его конструкциями CSS, отвечающими за визуализацию структуры меню. Пример PS-скрипта: $URL = "http://kom-ad01-sp-mys.holding.com" $SuiteBarText = ' <style type="text/css"> .menu, .menu ul { margin: 0; padding: 0; list-style: none; } .menu li, .menu ul a { position: relative; } .menu > li { float: left; } .menu > li.floatr { float: right; } .menu li > a { display: block; } .menu ul { position: absolute; display: none; width: 170px; } .menu ul ul { top: 0; left: 170px; } .menu li:hover > ul { display: block; } .menu a { text-decoration: none; } .menu > li > a { color: #fff; /*font-weight: 400; font-size: 13px;*/ line-height: 18px; padding: 6px 15px; } .menu > li:hover > a { background-color: #4b9bd7; color: #ffffff; border-left: none; padding-left: 15px; border-right: 0px solid #707070; margin: 0px 0 0 0px; } ul.menu li a { -webkit-transition: background-color 80ms ease-in-out; -moz-transition: background-color 80ms ease-in-out; -o-transition: background-color 80ms ease-in-out; -ms-transition: background-color 80ms ease-in-out; transition: background-color 80ms ease-in-out; } .menu ul li a { -webkit-transition: background-color 20ms ease-in-out, color 20ms ease-in-out; -moz-transition: background-color 20ms ease-in-out, color 20ms

В разных источниках информации о веб-сервере IIS можно встретить рекомендации касающиеся выполнения периодических перезапусков пулов приложений — Application Pools Recycling. Очевидно, что это имеет непосредственное отношение и к пулам приложений IIS, используемых в SharePoint Server 2013. Как я понял, большинство пулов, связанных с SharePoint, уже настроены на автоматический перезапуск (в основном раз в сутки в ночное время). Это можно увидеть, если открыть свойства Recycling любого из пулов Например, пул приложений, отвечающий за сайт Центра администрирования SharePoint, у меня уже настроен на автоматический перезапуск ежедневно в 02:11, хотя специально такой настройки я не производил. Следовательно, по утрам возникает ситуация, когда первый пользователь, обратившийся к веб-узлу, пул которого перезапускался ночью, может получить задержку открытия веб-страниц. Чтобы решить эту проблему, можно создать так называемый “прогревочный” (warm-up) скрипт, который будет выполняться после перезапусков пулов IIS. Задача у такого скрипта одна – выполнить простейший запрос ко всем используемым веб-узлам SharePoint, заставив тем самым IIS выполнить запуск соответствующих экземпляров приложений с последующим рендерингом страниц возвращаемых по запросу. На глаза попались два варианта подобных скриптов: Вариант #1. Источник: TechDays.ru — ИТ-Альманах. (Lync\Exchange\SharePoint) Выпуск 1 Add-PSSnapin Microsoft.SharePoint.PowerShell $wc = New-Object net.WebClient $wc.Credentials = [System.Net.CredentialCache]::DefaultCredentials Get-SPSite | ForEach {$wc.DownloadString($_.url)} $caUrl = "http://sharepoint:8000" # URL центра администрирования $wc.DownloadString($caUrl) Вариант #2. Источник: Todd Klindt’s SharePoint Admin Blog — Using PowerShell to warm up SharePoint 2013 Add-PSSnapin Microsoft.SharePoint.PowerShell Get-SPWebApplication -IncludeCentralAdministration | ForEach-Object { Invoke-WebRequest $_.url -UseDefaultCredentials -UseBasicParsing } Такой скрипт нужно выполнять после регламентных периодических перезапусков пулов и перед началом активности пользователей, чтобы свести к минимуму ситуации с долгим открытием страниц у первых пользователей. Для этого сохраним его на WFE-сервере, например с именем SP2013-Warm-Up.ps1, и создадим в планировщике заданий Windows периодическое задание, которое будет выполняться например каждое утро в 06:30 от имени учётной записи фермы с командой запуска: powershell.exe -NoProfile -command "C:\Tools\ScheduledScripts\SP2013-Warm-Up.ps1" Какой из двух представленных вариантов warm-up скрипта наиболее праведный,

Иногда бывает нужно проверить учётные данные какой-либо определённой пользовательской учётной записи в домене Active Directory, да ещё и на определённом контроллере домена. В сети можно найти несколько вариантов PowerShell скриптов, решающих подобную задачу. При этом большинство из них представляют собой некий массив кода. Однако быстро можно выполнить задачу с помощью всего одного PS-командлета Get-ADDomain. Пример с указанием distinguishedName домена, NetBIOS-имени контроллера домена и имени конкретной учётной записи пользователя: Get-ADDomain -Identity "DC=sub,DC=holding,DC=com" -Server "kom-ad01-dc02" -Credential "SUB\petya" При выполнении будет выдан запрос на ввод пароля указанной учётной записи, и если учётные данные указаны верно, то будет выведена информация о домене, в противном случае возникнет ошибка типа: “Get-ADDomain : Неправильное имя места назначения неверно, или сервер отклонил учетные данные клиента.”

В прошлый раз мы рассматривали обновление прошивки Integrated Lights-Out 2 (iLO2) до версии 2.27 на серверах HP ProLiant DL360/380 G5 c Windows Server 2012 R2 с помощью пакета установки, распространяемого через VCRM. В конце сентября и начале октября этого года появились новые версии прошивок iLO2 а также BIOS, относящихся в частности к этому же поколению серверов. Наверно можно было бы пропустить эти обновления «мимо ушей», если бы не степень критичности уязвимостей, которые исправляются этими обновлениями. Обновление iLO2 до версии 2.29 Относительно iLO информацию о проблемных версиях прошивок можно найти в бюллетене безопасности HP — ID c04486432 — HPSBHF03151 rev.4 — HP Integrated Lights-Out 2 and 4 (iLO 2, iLO 4), Chassis Management (iLO CM) on Proliant, Remote Denial of Service, Execution of Code, Elevation of Privilege. Как видно из этого документа, проблема безопасности распространяется в том числе и на рассмотренную нами в прошлый раз версию прошивки 2.27 для iLO2. Поэтому нам обязательно нужно выполнить обновление прошивки. Причём обновляться нужно не на следующую версию 2.28, которая имеет уже известные проблемы с JRE, описанные в документе ID c04818378 — Advisory: HP Integrated Lights-Out 2 (iLO 2) — Unable to Launch Java Remote Console with Java Runtime Environment (JRE) Versions 7 and 8 when TLSv1.1 and TLSv1.2 Are Enabled. Поэтому обновляться будем сразу на текущую версию 2.29, с момента выхода которой прошло уже достаточно времени. FIXES: - The Java IRC will not start when JRE versions 7 or 8 are installed and TLS 1.1/1.2 is enabled. - Addressed the vulnerability mentioned in CVE-2015-4000 and SSRT102268 (client-side SSL/TLS connections). Как и раньше, новую версию прошивки можно загрузить с сайта HP по ссылке: http://www.hp.com/support/ilo2. По указанной ссылке откроется страница загрузки HP Integrated Lights-Out 2 (iLO 2) Firmware for ProLiant G6 Servers, где выберем любую наиболее подходящую нам ОС, например Microsoft Windows Server 2008 R2 и

Давно подумывал о внедрении выделенного сетевого балансировщика, который бы мог, с одной стороны, работать в режиме высокой доступности (кластеризация узлов балансировщика), а с другой стороны, мог бы повысить уровень контроля доступности балансируемых веб-ресурсов. Всевозможные программно-аппаратные решения, как вариант, не рассматривались из-за их высокой стоимости, особенно в контексте реализаций высокой доступности. В эпоху повсеместного применения виртуализации, в качестве более доступного и масштабируемого решения, само собой напрашивается программное решение в виде сконфигурированной виртуальной машины под ту или иную платформу виртуализации. Начал изучать соответствующие варианты. Одними из основных критериев выбора были такие очевидные вещи, как отсутствие финансовых затрат, простота управления (желательно через веб-интерфейс), поддержка высокой доступности. Выбор был сделан на проекте Zen Load Balancer Community Edition (далее ZenLB). Однако попытка более или менее полноценно внедрить это решение на платформе виртуализации Microsoft Hyper-V без дополнительных трудозатрат оказалась безуспешной. Дело в том, что все бесплатные балансировщики, являющиеся ответвлением своих старших коммерческих “братьев”, в своей базовой конфигурации имеют ряд совершенно умышленных ограничений. ZenLB не стал исключением в этой ситуации, и поставляется в виде ISO-образа (zenloadbalancer-distro_37.iso размером 243MB) пред-настроенного дистрибутива 32-битной версии Linux Debian 6. Мои попытки заставить адекватно работать виртуальные машины Hyper-V с этим 32-битным дистрибутивом положительного результата не дали. То есть, на первый взгляд, система устанавливалась и работала, но попытка перезагрузки ВМ, инициированная из гостевой ОС, практически всегда приводила к зависанию ОС в самом начале процесса загрузки, и лечилось это только путём полного выключения (Power Off в консоли Hyper-V Manager) и повторного включения ВМ. Позже выяснилось, что в данной проблеме я не одинок, и эта проблема загрузки касается не только Debian, но и других 32-битных дистрибутивов Linux. А здесь дяденька из Microsoft Open Source Technology Center вообще намекнул, что я зря трачу время. Пришлось изменить вектор изучения вопроса. Помимо готового дистрибутива из apt-репозитория http://zenloadbalancer.sourceforge.net/apt/x86 v3/ можно загрузить *.deb пакет ZenLB вместе с пакетами-зависимостями, которых, как

Прочитав предыдущую заметку, один из моих коллег высказал замечание о том, что использование внешних балансировщиков может вызвать такой побочный эффект, как искажение информации в логах на бак-энд веб-серверах IIS об адресе клиента, который выполняет запросы к веб-серверу. То есть возникает потенциальная угроза того, что в нужный момент будет невозможно достоверно определить адрес клиента, обращающегося к веб-серверу находящемуся за таким балансировщиком. Посмотрев в лог веб-сервера IIS, который в моём случае выступал в качестве бак-энда, я обнаружил подтверждение описанной проблемы. В поле, где должен был отображаться IP адрес клиентского компьютера, был указан IP адрес балансировщика, через который к веб-серверу прошёл клиентский запрос: #Software: Microsoft Internet Information Services 8.5 #Version: 1.0 #Date: 2015-12-03 12:05:33 #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken 2015-12-03 13:48:19 10.1.0.93 GET /help - 8080 KOM\petya 10.1.0.211 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko http://kom-ad01-appvcl.holding.com:8080/ 200 0 0 30 Если говорить об этой ситуации применительно к ZenLB, то он для ферм балансировки HTTP использует функционал pound, который в свою очередь, по некоторой информации, добавляет в заголовки HTTP-пакетов информацию о первичном IP клиента. Чтобы проверить это, на бак-энд веб-сервер, расположенный за балансировщиком ZenLB, был установлен анализатор трафика Microsoft Message Analyzer, который показал, что среди заголовков, приходящих в запросе к IIS есть заголовок X-Forwarded-For, который и содержит IP адрес конечного клиента. Таким образом, всё, что нам нужно сделать, это объяснить нашему веб-серверу IIS то, каким образом необходимо логировать приходящие запросы клиентов. В используемом в нашем случае IIS 8.5 в составе Windows Server 2012 R2 имеется встроенная возможность, называемая Enhanced Logging, которая позволяет расширять возможности базового логирования IIS. Это позволит нам изменить используемый по умолчанию формат логирования, расширив его заголовком X-Forwarded-For. Для этого перейдём на веб-сервере в оснастку IIS Manager, выберем веб-сайт, который предоставлен пользователям через внешний балансировщик и в разделе настроек Health and Diagnostics выберем Logging В настройках параметров

На одном из хостов виртуализации в оснастке Hyper-V Manager было обнаружено, что после одного (некорректно выполненного) из предыдущих заданий резервного копирования виртуальной машины средствами System Center 2012 R2 DPM появилась контрольная точка (Checkpoint), для которой в меню действий отсутствует возможность удаления. На Microsoft есть статься по этому поводу KB3059372 — You can’t delete a recovery checkpoint for a virtual machine in Data Protection Manager, в которой в качестве решения приводится отсылка на другу статью TechNet Articles — Manually Merge .avhd to .vhd in Hyper-V. Однако удалить такую точку восстановления можно более простым способом с помощью PowerShell. Выключаем виртуальную машину и выполняем на хосте виртуализации команду удаления точек восстановления: Get-VMSnapshot -VMName "KOM-AD01-DC02" | Remove-VMSnapshot После удаления точки восстановления произойдёт слияние дисков виртуальной машины (для этого мы предварительно и выключили виртуальную машину). Поэтому, возможно, будет резонно пересоздать группу защиты в DPM для данной виртуальной машины, так как подобное слияние дисков может вызвать существенное увеличение раздела точек восстановления (Recovery point volume) для данной ВМ.

После того, как я перебрался на Windows 10, мне очень досаждала одна «кака» в новой системе. Если войти в систему стандартным пользователем и запустить в этой сессии какое-либо приложение от имени другой административной учетной записи (так называемый запуск от имени администратора), например тот же файловый менеджер, то при попытке открытия свойств любого файла или каталога в этом приложении мы получим ошибку: В английском варианте звучит, как «The properties for this item are not available«. Сначала была мысль о том, что в новой системе более суровые настройки безопасности и не все приложения ещё умеют с ними правильно работать. Однако позже, когда я стал замечать такую ошибку и в приложениях типа Internet Explorer, понял что «что-то здесь не чисто». По некоторой информации (см.комментарии) не так давно такое поведение системы было классифицировано как баг, и вроде как даже пообещали попатчить это дело. Однако пока исправления нет, можно воспользоваться ручным методом решения проблемы – правкой ключа системного реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{448aee3b-dc65-4af6-bf5f-dce86d62b6c7} Чтобы у нас появилась возможность изменять значения внутри этого ключа, нам потребуется сменить Владельца с TrustedInstaller например на локальную группу администраторов. После этого у нас появится возможность удалить параметр RunAs. Для вступления изменений в силу перезагрузка системы не потребуется, и теперь окно свойств объектов будут открываться без вопросов.

Сегодня узнал хорошую новость. Сообщесто .NET Foundation анонсировало новый проект – редактор блогов Open Live Writer (OLW) на базе только что открытых исходных кодов Windows Live Writer 2012 (WLW) из состава Windows Essentials. Ознакомится с командой разрабочитков, включившихся в проект, и скачать инсталлятор текущей версии OLW можно со специально созданного сайта. На данный момент OLW имеет версию 0.5 и его работа оптимизирована под Windows 10. В моём случае на Windows 10 установка OLW (0.5.0.0) безболезненно прошла рядом с установленным WLW 12 (16.4.3528.311) и оба редактора сохранили работоспособность. Будет ли работать OLW на Windows 7/8 сказать пока не могу, надо проверять. Краткий список изменений, выполненных в текущей версии OLW в отличие от исходной версии WLW 2012 можно найти здесь. Планы по развитию OLW можно увидеть в RoadMap проекта. Если вы решите примкнуть к сообществу активных пользователей OLW и обнаружите какой-либо баг, то его можно зарегистрировать здесь. В любом случае, после того как исходники WLW стали публично доступными, продолжать использовать WLW отстраняясь от OLW – решение неправильное, даже с точки зрения безопасности. Так что предлагаю обновиться всем и акивно подключиться к развитию продукта. Данный пост, кстати написан и опубликован уже из OLW

После развёртывания новой версии HP 3PAR Virtual Service Processor (VSP) 4.4 на виртуальной машине Hyper-V при попытке установки агента System Center 2012 R2 Operations Manager (SCOM) на OC этой виртуальной машины Red Hat Enterprise Linux (RHEL) Server 6.1 столкнулся с ошибкой мастера обнаружения SCOM, говорящей о невозможности выполнения одной из команд при подключении по протоколу SSH. SSH connection error Failed during SSH discovery. Exit code: -1073479115 Standard Output: Standard Error: Exception Message:An exception (-1073479115) caused the SSH command to fail - Server refused to start a shell/command Предыдущий опыт развёртывания агента SCOM на VSP 4.3.0 такой проблемы не выявил, хотя версия RHEL в том случае была таже, что и сейчас. По всей видимости в новой версии VSP произошли какие-то изменения с базовой настройкой SSH. Посмотрел в лог /var/log/secure и заметил, что во время попытки обнаружения со стороны SCOM на нашем RHEL-сервере появляются сообщения: Dec 16 10:17:06 SP0001652937 sshd[20239]: subsystem request for sftp Dec 16 10:17:06 SP0001652937 sshd[20239]: subsystem request for sftp failed, subsystem not found «По совету друзей» в конфигурационный файл /etc/ssh/sshd_config добавил строчку: Subsystem sftp /usr/libexec/openssh/sftp-server После перезапустил SSH: # /etc/init.d/sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] Попробовал снова. Далее снова столкнулся с ошибкой «Signed certificate verification, operation was not successful», но она уже была знакома и её решение было ранее описано. После исправления этой ошибки процедура обнаружения и настройки агента SCOM завершилась успешно.

Программный контроллер управления точками доступа UniFi может быть развёрнут как под управлением OC Microsoft Windows так и под управлением OC Linux. В этой заметке будет рассмотрен пример установки UniFi v4.7.6 Controller на свежеустановленную ОС Ubuntu Server 14.04 LTS 64-bit. Актуальная на данный момент версия контроллера 4.7.6 является hotfix release, поэтому замечания об установке в среде Linux можно будет найти в предудущем релизе — UniFi Updates Blog — UniFi 4.7.5 is released. Для начала добавим на нашем Ubuntu-сервере 2 дополнительных apt-репозитория в source list: echo 'deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti' | sudo tee -a /etc/apt/sources.list echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | sudo tee -a /etc/apt/sources.list Затем добавим PGP ключи для доверия пакетам (первый для unifi, второй для mongodb): sudo apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50 sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10 Если наш сервер подключен к Интернет через прокси, то возможно получение ошибки таймаута соединения с сервером ключей. В таком случае для начала проверим есть ли в конфиге APT информация о прокси: cat /etc/apt/apt.conf Должна присутсвовать запись типа: Acquire::http::Proxy "http://User:Password@ProxyServer:Port"; Но этой настройки может оказаться недостаточно. Создадим переменные окружения для текущего пользователя, в которые запишем параметры прокси: export https_proxy=https://User:Password@ProxyServer:Port export http_proxy=http://User:Password@ProxyServer:Port Проверим создались ли переменные: env | grep proxy Повторим попытку добавления ключей с использованием переменных окружения текущего пользователя (в команду sudo добавляем ключик -E): sudo -E apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50 sudo -E apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10 Теперь «со спокойной душой» обновляем APT и устанавливаем контроллер с зависимостями: sudo apt-get update sudo apt-get install unifi будет предложено установить ряд дополнительных пакетов, соглашаемся: Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: binutils ca-certificates-java icedtea-6-jre-cacao icedtea-6-jre-jamvm java-common jsvc libavahi-client3 libavahi-common-data libavahi-common3 libcommons-daemon-java libcups2 libjpeg-turbo8 libjpeg8 liblcms2-2 libnspr4 libnss3 libnss3-nssdb mongodb-10gen openjdk-6-jre-headless openjdk-6-jre-lib tzdata-java Suggested packages: binutils-doc default-jre equivs java-virtual-machine

Это заметка для тех, кто пользуется услугами виртуального хостинга для размещения своих сайтов, задумывается о выборе другого хостинг-провайдера, но не знает как выполнить перенос сайтов и с чего вообще начать. Она кратко описывает наш опыт выбора нового хостинг-провайдера и процедуры переноса блога на движке WordPress и форума на движке phpBB на мощности этого хостера. Начну с того, что недавно я получил письмо от российского интернет-хостера SmartApe с предложением о сотрудничестве. Так как ранее об этом хостере я ничего не слышал, стал с любопытством изучать предлагаемые им услуги. Конкретно меня интересовали услуги виртуального хостинга для потенциального размещения сайтов нашего блога и форума. Не то, чтобы у нас стояла какая-то сверхзадача по смене хостера по причине того, что на текущий момент наш хостер нас чем-то явно не устраивал. Ситуация на перспективу выглядела так, что с текущим положением вещей нам пришлось бы менять тарифный план на более дорогостоящий, так как, по мере увеличения контента блога, рос и объём используемого на хостинге дискового пространства, к тому же показатели посещаемости с начала перехода на платный хостинг медленно, но верно увеличивались (спасибо нашим читателям). Изначально при переходе с WordPress.com на платный хостинг IHC.ru был выбран самый скромный тарифный план «Лёгкий», которого хватало до определённого момента, пока не стало ясно, что в силу вышеописанных причин и повышенной активности DDoS-ботов, нам таки придётся сменить тарифный план на более серьёзный. И к моменту написания этой статьи мы уже несколько месяцев использовали тарифный план «Оптимальный» с соотношением ограничений и стоимости, которые хорошо видно на скриншоте, сделанном на сайте хостера Однако результаты работы второй половины прошлого года показали, как я уже говорил, не очень приятную активность всевозможных сетевых ботов, которые периодически «долбили» блог тысячами запросов. По результатам этих атак хостер слал нам грозные письма, как правило, с показателями высокой загрузки процессора серверов хостинга и предупреждением о возможной блокировке услуги, если мы

В прошлой заметке я упоминал о том, что при смене хостинг-провайдера можно выполнить трансфер домена между старым и новым хостером. Для этого, как минимум, потребуется выяснить какая организация является главным Регистратором нашего домена и написать в эту организацию письмо с просьбой о выполнении трансфера между хостерами, в большинстве случаев приложив у этому письму скан паспорта (для подтверждения личности владельца домена). Кроме того, у каждого Регистратора могут быть свои особенные условия и требования необходимые для удовлетворения такой заявки. Однако существует и другой вариант управления своим доменом. Можно выполнить трансфер домена непосредственно к самому Регистратору и получить полный доступ к управлению доменом прямо с сайта Регистратора. Это позволит нам отойти от зависимости от какого-то конкретного хостинг-провайдера и свободно распоряжаться своим доменом без необходимости выполнять трансфер домена при каждой очередной смене хостинга. Однако стоит понимать, что такая «свобода» имеет свою цену, и если домен будет находиться у Регистратора на нашем прямом управлении, то нам ежегодно придётся платить за доменное имя в несколько раз больше. Например, при регистрации нового домена в зоне .RU через какого-либо хостинг-провайдера стоимость ежегодной оплаты за такой домен будет колебаться в районе 140-150 рублей, в то время как при регистрации домена непосредственно у организации Регистратора стоимость ежегодной оплаты уже будет составлять в районе 500-650 рублей. Думаю здесь, чтобы внести ясность в терминологию, стоит пояснить то, как я понимаю и разделяю для себя понятия хостинг-провайдера и Регистратора в контексте разговора о регистрации/продлении доменных имён Интернета. Регистратор – это организация имеющая право регистрировать и продавать имена в доменах первого уровня типа RU, COM, NET и т.п. в соответствии с договорённостями (аккредитация) и правилами международной Корпорации по управлению доменными именами и IP-адресами — Internet Corporation for Assigned Names and Numbers (ICANN). В интернете без труда можно найти список аккредитованных Регистраторов для доменов верхнего уровня, например для зоны RU такой список можно найти здесь

Сегодня практически любой виртуальный хостинг в качестве дополнительной услуги предлагает возможность создания почтовых ящиков для вашего домена, однако удобство работы с такими ящиками иногда оставляет желать лучшего. Чтобы поднять качество работы с почтой домена можно воспользоваться бесплатным сервисом от Яндекс Почта для домена. Данный сервис позволяет привязать почту вашего домена к почтовым серверам Яндекс с возможностью создания до 1000 безлимитных почтовых ящиков с использованием всех преимуществ сервиса Яндекс.Почта, таких как автоматическая проверка антивирусом, спам фильтры, доступ через веб-интерфейс, доступ с мобильных устройств и через прямое подключение по протоколам SMTP/POP3/IMAP. Одним из основных этапов настройки привязки домена к почтовой системе Яндекса является создание специальных записей в DNS-зоне вашего домена. Чтобы максимально упростить и автоматизировать данную процедуру, можно произвести делегирование домена на NS-серверы Яндекса, то есть фактически воспользоваться ещё одним бесплатным сервисом DNS-хостинг Яндекса. В этой заметке мы поэтапно рассмотрим процедуру подключения почты домена к почтовым серверам Яндекса а также делегирование домена серверам Яндекса на примере нашего домена IT-KB.RU Регистрируем аккаунт на Яндексе Для работы с Почтой для домена необходим аккаунт Яндекса, используя который, мы в дальнейшем будем управлять почтой. На данный момент к каждому аккаунту можно подключить до 50 доменов. Зарегистрируемся и получим аккаунт Яндекс, если этого ещё не было сделано ранее. Подключаем домен к Яндексу После того, как мы авторизовались на сайте Яндекс используя созданный аккаунт, откроем cтраницу добавления домена, укажем имя нашего домена и нажмём кнопку Подключить домен. После добавления домена, нам нужно будет подтвердить то, что мы являемся его владельцем. На веб-странице будет отображаться статус Домен не подтверждён и будет предложено три варианта действий, которыми мы сможем подтвердить владение доменом. Из трёх предложенных вариантов я выбрал первый вариант с размещением файла в корневом каталоге сайта. После того, как указанный файл размещен, жмём кнопку Проверить владение доменом. После успешной проверки нас перенаправят на страницу настройки

Если по аналогии с ранее описанным примером вы настроите привязку своего почтового домена к почтовым серверам Яндекс, то после этого, вполне возможно, у вас появится желание использовать для своих сайтов, размещённых на внешних хостингах, почтовые серверы Яндекса для отправки почты. Отправка почты с сайтов может использоваться, например, под всевозможные рассылки зарегистрированным пользователям форума, для механизма оповещений о комментариях в блоге, и т.п. задачи. В этой коротенькой заметке я покажу пример настройки блога на движке WordPress 4.4 и форума на движке phpBB 3.1 на использование для отправки почты внешних SMTP-серверов Яндекс. Информацию об актуальных параметрах подключения к SMTP от Яндекс всегда можно найти в онлайн-справке: Яндекс.Почта — Настройка почтовых программ WordPress и SMTP от Яндекс По умолчанию движок блога использует отправку почты через локальный почтовый сервер хостинга сайта. Чтобы переопределить такое поведение, достаточно установить один из множества, в том числе и бесплатных, плагинов WordPress. Я выбрал бесплатный плагин Postman SMTP Mailer/Email Log, который прост, удобен и практически не имеет нареканий со стороны WP-сообщества. После установки плагина в панели администрирования WP переходим в Настройки > Почтовик SMTP и запускаем Мастер настройки, в котором дойдя до шага указания сервер исходящей почты задаём smtp.yandex.ru Затем указываем 465 порт с требованием аутентификации. После указываем данные почтового ящика в нашем домене, подключённом к Яндекс.Почта через описанную ранее услугу Почта для домена. После сохранения основных настроек мастера перейдём в дополнительные настройки и укажем уровень безопасности SMTP соединений Например так: Теперь можно воспользоваться функцией отправки тестового письма и убедиться в том, что отправка успешно выполняется. Как видим, отправка почты успешно работает. В случае же возникновения проблем с отправкой, смотрим Расшифровку сессии. phpBB и SMTP от Яндекс В случае с форумным движком phpBB 3.1 настройка оказалась ещё проще, так как в этом случае не потребовалось установки каких-то дополнительных модулей. По сути вся настройка сводится к изменению параметров

System Center 2012 R2 DPM — An unexpected error occurred while the job was running. (ID 104 Details: The device is not connected (0x8007048F))

Ограничение скорости Интернет для разных категорий пользователей на прокси-сервере Squid (Delay pools)

Изменение загружаемого по умолчанию ядра в Ubuntu Linux

System Center 2012 R2 App Controller Hight Availability на базе узлов кластера Virtual Machine Manager

System Center 2012 R2 DPM —Определяем группу защиты по части символической ссылки из ProtectableObjectLoadPath

SharePoint 2013 —Многоуровневое меню в Suite Bar

SharePoint Server 2013 —Перезапуск пулов IIS и прогревочный скрипт

PowerShell —Быстрый способ проверить учётные данные пользователя в Active Directory

Обновляем Firmware BIOS & iLO2 на серверах HP ProLiant DL360/380 G5

Высоко-доступный балансировщик Zen Load Balancer (ZenLB) Community Edition на базе 64-битной ОС Ubuntu Server 14.04

Балансировщик Zen Load Balancer (ZenLB) и логи на Back-End веб-серверах IIS

Hyper-V Manager —не удаляется контрольная точка "Backup"после задания DPM

Windows 10 —Ошибка "Свойства этого элемента недоступны"при попытке открыть свойства Windows Explorer из приложений запущенных от имени администратора

Встречайте Open Live Writer —старый Windows Live Writer на новый лад

Ошибка при работе мастера обнаружения SCOM при подключении к HP VSP 4.4 (RHEL 6.1) — Failed during SSH discovery. Exit code: -1073479115

Установка UniFi v4.7.6 Controller на Ubuntu Server 14.04 LTS

Выбираем Pоссийского хостинг-провайдера SmartApe и переносим сайты на базе WordPress и phpBB на новый хостинг

Забираем управление доменом —выполняем трансфер домена от хостинг-провайдера к Регистратору на примере REGTIME-RU

Делегирование DNS-домена на серверы Яндекса и подключение к бесплатной услуге Яндекса "Почта для домена"

Отправка почты в WordPress 4.4 и phpBB 3.1 через внешние SMTP-серверы на примере Яндекс