После регистрации домена организации в Microsoft 365, Outlook клиентов стал с завидной регулярностью запрашивать вход с учетной записью Microsoft, хотя организация использует собственный локальный Exchange On-Premises:
Для решения данной проблемы нужно добавить в реестр на затрагиваемых рабочих станциях следующий ключ:
в ветке HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover создаем ключ DWORD с именем ExcludeExplicitO365Endpoint и присваиваем значение 1
Настраивая "Повсеместный доступ" через Панель мониторинга Windows Server 2016 Essentials, включил возможность подключения по VPN, создал подключение на клиентском компьютере. Подключение прошло успешно, однако доступ к каким-либо ресурсам в удаленной сети не работал, пинги не работали. Недолгое исследования показало, что клиентский компьютер не получает ip-адрес от сервера. Было решено на сервере установить оснастку "Маршрутизация и удаленный доступ" и проверить настройки VPN, что я и сделал. Однако, оснастка выдала следующее - "На этом сервере отключен устаревший режим" и с помощью оснастки просмотреть и изменить настройки нельзя, нужно использовать PowerShell:
Немного погуглив и поразмыслив, пришел к выводу, что скорее всего проблема в том, что RRAS почему-то не может арендовать ip для своих клиентов у DHCP роутера. Было решено назначить статический пул адресов для клиентов VPN, делается это следующей командой PowerShell:
Если вы хотите получить доступ к настройкам все же через консоль "Маршрутизация и удаленный доступ", нужно удалить соответствующую роль и компоненты и установить их заново, но уже не через "Панель мониторинга" Essentials, а средствами сервера.
Была у меня задача обновить тривиальную инсталляцию Exchange 2016 CU5 до CU7. Один контроллер домена на отдельном сервере, один сервер Exchange, операционная система Windows Server 2016. CU7 установился без проблем, правда устанавливался около двух часов, несмотря на то, что использовались SSD-диски. Все тесты прошли успешно и с чувством глубокого удовлетворения я отправился спать. Просыпаюсь я утром, пробую войти в OWA - сайт недоступен... Запускаю Outlook - ошибка подключения... Захожу на сервер и наблюдаю такую картину - все службы Exchange остановлены и находятся в состоянии Disabled. Оба-на... Смотрю журналы, что было ночью, и выясняется, что через Windows Update прилетело обновление Security Update For Exchange Server 2016 CU7 (KB4045655), его установка прошла неудачно. Решил попробовать скачать обновление и установить вручную. Установка завершается неудачей, установщик сообщает, что изменений произведено не было. Перевожу все необходимые службы Exchange в состояние Automatic, перезагружаю сервер, однако службы не стартуют - "The service did not respond to the start or control request in a timely fashion". Супер, отличный подарок на 23 февраля, я просто мечтал получить полностью нерабочий Exchange и провозиться с ним весь праздничный день Пробую установить обновление повторно - попытка также оканчивается неудачей, при этом установка прерывается на моменте "Stopping services". Решаю погуглить и обнаруживаю, что проблема такая, оказывается, не у меня одного, и не только с этим обновлением Как выяснилось, причина неудачи установки обновления в том, что для остановки служб используется командлет Stop-SetupService, которого нет в системе по умолчанию. Наблюдать это можно открыв C:\ExchangeSetupLogs\ServiceControl.log и обнаружив там сообщение об ошибке "The term 'Stop-SetupService' is not recognized as the name of a cmdlet, function, script file, or operable program."
Проблема решается путем добавления профиля PowerShell с ярлыком Stop-SetupService: New-Alias Stop-SetupService Stop-Service. После этого установка обновления проходит без проблем и после перезагрузки сервера все службы стартуют нормально и работа Exchange полностью восстанавливается. Фууух...
3. Создаем файл "profile.ps1" в каталоге "C:\Windows\System32\WindowsPowerShell\v1.0", содержащий следующую команду:
New-Alias Stop-SetupService Stop-Service
4. Запускаем командную строку с повышением (от имени администратора) и запускаем из нее обновление Exchange2016-KB4045655-x64-en.msp. Запуск с повышением нужен потому, что если так не сделать, то иногда случается, что после установки перестает работать OWA и ECP.
5. После успешной установки перезагружаем сервер по запросу инсталлятора и, вуаля, получем снова рабочий Exchange 8)
Вот такие сырые и не до конца отлаженные обновления могут иногда прилететь от Microsoft через Windows Update... Будьте внимательны и разворачивайте обновления и CU вначале в тестовой среде, и только потом в рабочей. Успехов!
Если вы столкнулись с проблемой удаления папки с компьютера под управлением Windows, при этот система выдает сообщение вроде "Не удалось найти элемент", "Папка не пуста" или вроде того, то может помочь следующий способ:
Берем архиватор, например, Winrar, и архивируем эту папку, при этом в свойствах указываем "Удалить файлы после упаковки". После архивации папка будет удалена, затем удаляем и полученный архив.
Если отображаемое в журналах WinPower (утилита управления ИБП Ippon) время не соответствует системному, то, скорее всего, это происходит из-за того, что в составе Java, устанавливающейся вместе с этой утилитой, присутствуют устаревшие данные о часовых поясах.
Для того, чтобы исправить эту проблему, нужно обновить данные о часовых поясах с помощью Timezone Updater Tool.
1. Скачайте TZUpdater tool и распакуйте куда-либо, поместите файл tzupdater.jar из архива в "C:\Program Files (x86)\MonitorSoftware\jre\bin" . 2. Запустите командную строку от имени администратора и перейдите в каталог "C:\Program Files (x86)\MonitorSoftware\jre\bin" . 3. Запустите в командной строке команду java -jar tzupdater.jar -l 4. Перезапустите WinPower, время должно начать соответствовать системному.
Если затрагиваемая система не подключена к Интернету, то вначале надо скачать архив с новыми временными зонами, например, в папку C:\tz, а затем установить их командой java -jar tzupdater.jar -l file:///tz/tzdata-latest.tar.gz
Такие ошибки при запуске бэкапа могут возникать по причине наличия остатков в реестре от VSS-провайдеров, которые ранее были удалены из системы. В моем случае ошибки появлялись на хостовой машине Hyper-V на Windows Server 2008 R2 при запуске резервного копирования. Запустив команду vssadmin list providers я увидел, какие VSS-провайдеры зарегистрированы у меня в системе, и сравнил их с PID-ами тех, которые были в ошибках. Выяснилось, что ошибки возникали в отношении провайдеров, которые мне были не нужны и которых я ранее удалил из системы. Далее я удалил записи в реестре от этих провайдеров следующим образом:
1) Находим в реестре ключ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VSS\Providers\] 2) На всякий случай создаем резервную копию этого ключа 3) Удаляем ключи с соответствующим PID 4) Перезапускаем службу "Microsoft Software Shadow Copy Provider" 5) Запускаем бэкап и смотрим на наличие ошибок. Если ошибки появились вновь, перезагружаем систему.
Начиная с Windows Server 2012 компания Microsoft изменила процедуру сжатия (compact) файлов виртуальных жестких дисков (vhdx) - перед сжатием такого файла нужно вначале присоединить (mount) его к системе в режиме "Только чтение" (Read-only), а потом уже выполнять процедуру сжатия. Затем файл нужно отсоединить (dismount).
Присоединить и отсоединить vhdx-файл можно как с помощью оснастки "Управление дисками" (Disk Management), так и с помощью PowerShell.
Присоединяем vhdx:
Ставим галку "Read-only" (Только чтение):
Сжимаем vhdx используя Edit Disk в консоли Hyper-V:
Отсоединяем vhdx с помощью оснастки "Управление дисками":
Для PowerShell набор команд будет выглядеть следующим образом (запускать PowrerShell нужно с повышением):
В случае, если на сервере не установлены Службы удаленных рабочих столов, сертификат RDP можно изменить следующим образом:
1) Поместить сертификат в хранилище сертификатов локального компьютера в Личное:
2) Открыть сертификат, найти в свойствах его Отпечаток (Thumbprint), скопировать его, например, в Блокнот и удалить пробелы. Должно получиться что-то вроде 579a301318c5664f3b2bff0b88bf73d8bd2464dd.
3) Запустить PowerShell с правами администратора и выполнить следующие команды:
После перенастройки размещения CRL в Центре сертификации и перевыпуска сертификатов сервера перестала запускаться Панель мониторинга (Dashboard) роли Essentials Experience в Windows Server 2012 R2. При этом в Журнале приложений фиксировались следующие ошибки:
Event ID: 1026
Приложение: Dashboard.exe
Версия платформы: v4.0.30319
Описание. Процесс был завершен из-за необработанного исключения.
Сведения об исключении: Microsoft.WindowsServerSolutions.Common.ProviderFramework.ProviderException
Event ID: 1000
Источник: Application Error
Имя сбойного приложения: Dashboard.exe, версия: 6.3.9600.17393, метка времени: 0x54333ee9
Имя сбойного модуля: KERNELBASE.dll, версия: 6.3.9600.18007, метка времени: 0x55c4c341
Код исключения: 0xe0434352
Смещение ошибки: 0x000000000000871c
Идентификатор сбойного процесса: 0x6ec
Время запуска сбойного приложения: 0x01d15b3d5c8cdd17
Путь сбойного приложения: C:\Windows\system32\Essentials\Dashboard.exe
Путь сбойного модуля: C:\Windows\system32\KERNELBASE.dll
А в логе Панели мониторинга (C:\ProgramData\Microsoft\Windows Server\Logs\Dashboard.log) содержалось множество подобных сообщений:
[6636] 160130.223341.2577: PluginManager: Unable to retrieve digital certificate for C:\Windows\System32\Essentials\HEAddin.dll: Cannot find the requested object.
[6636] 160130.223341.2734: PluginManager: Unable to retrieve digital certificate for C:\Windows\System32\Essentials\OIMAddin.dll: Cannot find the requested object.
[6636] 160130.223341.2734: PluginManager: Unable to retrieve digital certificate for C:\Windows\System32\Essentials\GroupUIAddin.dll: Cannot find the requested object.
Для устранения проблемы необходимо запустить PowerShell с правами администратора и выполнить следующую команду:
Add-WssLocalMachineCert
Если выполнение команды завершится с ошибкой, необходимо перезагрузить сервер и снова запустить ее.
При подключении источника бесперебойного питания к серверу FreeNAS и настройке службы UPS встает вопрос, какой порт указывать в настройках, т.е. к какое имя порта, к которому подключен ИБП. Для того, чтобы определить, к какому порту подключен ИБП, запустите командную строку (Shell) и выполните следующую команду:
dmesg | grep -i usbus
Результатом выполнения команды будет список usb-портов и устройств, которые к ним подключены:
[root@msk-nas1 ~]# dmesg | grep -i usbus
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus1 on uhci0
usbus2: EHCI version 1.0
usbus2 on ehci1
usbus0: 480Mbps High Speed USB v2.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 480Mbps High Speed USB v2.0
ugen0.1: <Intel> at usbus0
uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
ugen1.1: <0x103c> at usbus1
uhub1: <0x103c UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen2.1: <Intel> at usbus2
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
ugen0.2: <vendor 0x8087> at usbus0
uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus0
ugen2.2: <vendor 0x8087> at usbus2
uhub4: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus2
ugen2.3: <vendor 0x0424> at usbus2
uhub5: <vendor 0x0424 product 0x2660, class 9/0, rev 2.00/8.01, addr 3> on usbus2
ugen0.3: <JetFlash> at usbus0
umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.10/10.75, addr 3> on usbus0
ugen0.4: <American Power Conversion> at usbus0
Ищите в списке название бесперебойника или производителя, в моем случае это American Power Converion, и определяете порт - в моем случае это ugen0.4. Указываете его в настройках:
Ошибка 800B0001 при попытке проверки обновлений Windows как правило возникает по "криптографической" причине - проблемы с сертификатами или подписями файлов WSUS.
Проверьте, не установлено ли на клиентских компьютерах какое-либо криптографическое ПО, например, КриптоПРО. Возможно, причина будет именно в нем - удалите его или обновите до более новой версии. В моем случае проблема была вызвана КриптоПРО 3.6, помогло обновление до версии 3.9. Существует "Исправление для устранения проблем с Windows update для КриптоПро CSP 3.6, 3.6 R2 и 3.6 R3", но оно мне не помогло.
Если после установки указанных обновлений на клиентских компьютерах при поиске обновлений возникает ошибка 80244010, повторите поиск 2-3 раза, как правило, ошибка уходит. Подробнее об ошибке 80244010 тут.
Если попытка удаления WSUS 3.0 завершается с ошибкой, то, возможно, поможет следующий способ:
1) Установите ключ реестра HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup\wYukonInstalled в значение 0 (ноль). 2) Удалите роль WSUS через Server Manager. 3) Удалите фичу Windows Internal Database (при необходимости).
Первый пункт сообщает инсталлятору WSUS, что база Windows Internal Database не установлена, в результате деинсталляция обычно проходит без проблем. В пункте 3 удаляется база данных WSUS. У меня проблема возникла на Windows Server 2008 R2.
Причиной ошибки отправки уведомления по электронной почте по квотам на папки или диски службой File Server Resource Manager может быть то, что у пользователя, который превысил квоту, в учетной записи в AD отсутствует e-mail. При этом в журнале сервера генерируется событие:
SRMSVC Event ID 12306, Error-specific details:
Error: IFsrmEmailExternal::SendMail, 0x8004531c, The parameter 'addresses' cannot be an empty string.
Parameter name: addresses
В частности, при просмотре деталей события можно обнаружить, что квоту превышает учетная запись NT AUTHORITY\SYSTEM или подобная:
У этих учеток нет адреса электронной почты, поэтому отправка не удается и генерируется сообщение ошибке. Если уведомление пользователей не требуется, то для решения проблемы его можно просто отключить, оставив только администраторов.
После установки SP3 на Exchange 2007 столкнулся с проблемой - при попытке создать новый получающий соединитель (коннектор) выводится сообщение об ошибке: Отклик Active Directory: 00000057: LdapErr: DSID-0C090C26, comment: Error in attribute conversion operation, data 0, vl 772. Происходит это потому, что в SP3 используются новые атрибуты Active Directory (AD), а в схеме AD их еще нет. Для того, чтобы они появились, требуется обновить схему. Для обновления схемы требуется запустить из каталога с дистрибутивом SP3 следующую команду (из командной строки с административными привилегиями):
Setup.com /prepareschema
Схема обновляется некоторое время. После обновления схемы коннекторы начинают создаваться без проблем.
Это же решение исправляет проблему создания соединителей при использовании функции "Устранение проблем сети" Windows Small Business Server 2008.
Изменить размер текста и других элементов (dpi) на экране терминального сервера на базе Windows Server 2008 R2 возможно только при непосредственном входе на него. При этом даже если вы изменили размер для определенной учетки, то при удаленном входе через терминальную сессию отображаться всё равно всё будет в обычном режиме - изменения размера для терминальных сессий не происходит.
Чтобы устранить эту досадную неприятность, специально для желающих менять dpi экрана в терминальных сессиях и на счастье бухгалтерам, работающим с 1С и плохо видящим мелкий шрифт, Microsoft выпустила хотфикс для решения этой проблемы Найти этот хотфикс и скачать можно тут http://support.microsoft.com/kb/2726399 Данное решение подходит и при подключении к удаленному рабочему столу Windows 7.
Дополнение: Если какие-то элементы не изменяют размер, например, размер текста в некоторых элементах, проверьте, не установлены ли у вас параметры окон и других элементов, отличные от параметров по умолчанию, в "Изменение цветовой схемы -> Прочие".
Чтобы настроить пересылку dns-запросов для определенного домена на определенный dns-сервер (Conditional DNS forwarding), можно использовать возможность инспектирования пакетов на Уровне 7 (Layer7 Protocols) в Firewall RouterOS.
Пример:
Имеем роутер MikroTik, версия RouterOS 6.27, ip-адрес dns-сервера на Микротике 192.168.15.1, требуется перенаправлять запросы для domain.local на dns-сервер домена Active Directory 192.168.55.2.
Для решения указанной задачи нужно выполнить в консоли RouterOS следующие команды:
Последнюю строку можно не добавлять, если у вас у вас уже есть каким либо образом настроенная маршрутизация пакетов в подсеть целевого dns-сервера. Если нужно добавить еще домены, нужно выполнить аналогичный набор команд для каждого домена, заменив имя домена и адрес dns-сервера на соответствующие.
После удаления одного знаменитого антивируса столкнулся с проблемой - перестали устанавливаться VPN-соединения с ошибкой 720: "Не удается подключится к удаленному компьютеру. Возможно потребуется изменение сетевой настройки подключения". При этом в Диспетчере устройств можно было увидеть устройства "Мини-порт глобальной сети (IP)", "Мини-порт глобальной сети (IPv6)" и "Мини-порт глобальной сети (Сетевой монитор)" с желтым треугольником предупреждения о невозможности запуска с ошибкой 10. Инициализация tcp/ip и winsock проблему не решила. В итоге проблему решил следующим образом:
1) Заходим с Свойства этих нерабочих устройств и заменяем их драйвер на "Адаптер замыкания на себя Microsoft KM-TEST". Делается это через закладку Драйвер->Обновить->Выполнить поиск драйверов на этом компьютере->Снимаем галку "Только совместимые устройства" и выбираем указанный драйвер. На предупреждение не обращаем внимания. Нужно это для того, чтобы система позволила удалить эти устройства и переустановила их заново - без этого система удалить их не дает. 2) Удаляем все устройства, на которых заменили драйвер. 3) Делаем рескан железа (Обновить конфигурацию оборудования), система найдет удаленные устройства и установит нужные драйвера. У устройств при этом не должно уже быть значка предупреждения о неработоспособности.
Все, после этого vpn должен начать подключаться без проблем. Возможно в каких-то случаях после всей этой процедуры нужно перезагрузить компьютер. Проблема у меня возникла на Windows 8.1 x64.
На одном из доменных компьютеров с Windows 7 столкнулся с проблемой - не применялась групповая политика компьютера, при этом в системном журнале компьютера регистрировалось событие с номером 1055:
Ошибка при обработке групповой политики. Не удалось разрешить имя компьютера. Возможные причины:
a) Ошибка разрешения имен на текущем контроллере домена.
b) Запаздывание репликации Active Directory (созданная на другом контроллере домена учетная запись еще не реплицирована на текущий контроллер домена).
При этом в Подробностях можно было видеть следующий дополнительный код ошибки:
ErrorCode 1331
ErrorDescription Вход в систему не произведен: учетная запись в настоящее время отключена.
На Технете существует статья по событию 1055, однако по ErrorCode 1331 там нет никакой информации. Имена на контроллере домена разрешались нормально, dcdiag никаких ошибок не показывал, с репликацией проблем не было, sysvol была доступна с проблемного компа, учетная запись компьютера конечно же была включена. При генерации Результирующей политики (RSoP) выдавалась следующая ошибка:
Инфраструктура групповой политики не удалось выполнить из-за указанной ниже ошибки.
Вход в систему не произведен: учетная запись в настоящее время отключена.
Примечание: из-за ошибки ядра групповой политики никакие другие компоненты групповой политики не выполнили обработку своей политики. Тем самым, информация о состоянии других компонентов недоступна.
В результате долгих раздумий и исканий выяснилось следующее - на компьютере под аккаунтом Локальная система (Local System аccount) были закэшированы реквизиты сторонней учетки для доступа к контроллеру домена. А именно от имени этого аккаунта идет обращение к КД для получения групповых политик компьютера. Т.е. при попытке получить групповые политики с контроллера домена обращение к нему шло от этой закэшированной учетки, которая действительно была отключена. Проблема решилась после удаления этой учетки из кэша, сделать это можно следующим образом:
1) С Технета качаем всем известный пакет Sysinternals PSTools, из него нам потребуется утилита PsExec 2) Запускаем командную строку от имени администратора и выполняем в ней PsExec.exe -i -s cmd.exe, в результате запустится командная строка под системной учетной записью 3) В этой командной строке запускаем rundll32.exe keymgr.dll, KRShowKeyMgr, в результате откроется окно "Сохранение имен пользователей и паролей", в котором можно увидеть все закэшированные учетки под системной учетной записью:
4) Удаляем ненужные учетки. Прежде всего нужно обратить внимание на те, которые используются для авторизации на КД. В моем случае тут была только одна учетка. 5) Перезагружаем компьютер, проверяем, как отработалась политика компьютера, и наслаждаемся жизнью
При изменении пути перенаправленной папки через групповые политики на новый путь, при этом когда сами данные физически продолжают оставаться в том же самом месте (например, в случае использования нового пути DFS или кластера), можно столкнуться с тем, что все файлы из папки будут удалены. Это может произойти тогда, когда в настройках перенаправления папки включен параметр "Move contents of ... to the new location" (Перенести содержимое ... в новое местоположение). Конечным действием операции переноса является удаление файлов из начального местоположения, но так как физически оно одно и тоже, происходит полное удаление всех файлов из перенаправленной папки. Будьте внимательны в таких случаях! Не забывайте снимать указанную галку в настройках перенаправления папки, либо включите параметр групповой политики "Verify old and new Folder Redirection targets point to the same share before redirecting" (Проверить перед перенаправлением, указывают ли старый и новый конечный объект перенаправления папки на один общий ресурс). Этот параметр находится в Computer Configuration/Polices/Administrative templates/Windows Components/Windows Explorer. При включении этой политики, Windows перед переносом файлов определяет путем записи временного файла - в одно и то же физическое место хранения происходит перенаправление или нет. В случае обнаружения, что папка перемещается в одно и то же место, происходит только изменение пути без операции копирования и удаления файлов.
При использовании перенаправленных папок (redirected folders) на компьютерах с Windows 7, 8, Vista на сетевые ресурсы DFS с включенным использованием Автономных файлов (Offline files) столкнулся со следующей проблемой - при попытке синхронизировать автономные файлы через Центр синхронизации операция зависает в статусе "Синхронизация ожидается" (Sync pending) и так никогда и не происходит. После изучения сайтов Microsoft с рекомендациями по настройке Автономных файлов и обзора зарубежного опыта отыскал таки проблему - для корректной работы синхронизации при использовании DFS в силу особенностей работы кэширования возможность использования Автономных файлов должна быть включена не только на уровне непосредственно Конечного объекта папки (Folder target), но и на уровне корня DFS. В настройках автономного режима сетевой папки, которая является корнем DFS, по крайней мере должно быть указано "Вне сети доступны только указанные пользователем файлы и программы". Далее уже на уровне Конечного объекта папки (Folder target) вы можете указывать, какие из них могут быть доступны автономно, а какие нет, в зависимости от вашей необходимости.
В моем случае указанный корень DFS использовался для хранения перемещаемых профилей пользователей и перенаправленных папок Мои документы и Рабочий стол. Пути имели следующий вид:
\\domain.local\data\profiles\ - тут хранились профили пользователей, для Folder target "profiles" использование автономных файлов отключено \\domain.local\data\userdata\ - тут хранились перенаправленные папки пользователей, для Folder target "userdata" автономные фалы были включены принудительно
На корне DFS "data" - автономные файлы были выключены принудительно. В итоге синхронизация через Центр синхронизация зависала в бесконечном "Синхронизация ожидается". Установка возможности кэширования на уровне корня решило проблему, при этом папка profiles не кэшируется, так как на ее уровне автономные файлы выключены.
Как известно, Microsoft поменяла принцип и технологию кэширования автономных файлов начиная с Windows Vista. В Windows XP кэш автономных файлов можно было сбросить в настройках автономных файлов путем клика на кнопку "Удалить файлы...", удерживая при этом SHIFT+CTRL. В результате появлялось окно с предложением инициализировать кэш и после перезагрузки кэш благополучно инициализировался:
В Windows Vista, Windows 7 (и скорее всего также и в Windows 8, не проверял) таким образом очистить кэш автономных файлов уже не получится. Для сброса кэша в указанных операционных системах нужно проделать следующее:
1) Запустить regedit и найти ветку HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CSC\Parameters 2) Создать в этой ветке параметр DWORD (32 бита) с именем FormatDatabase и значением 1. 3) Перезагрузить компьютер.
ВНИМАНИЕ!!! Перед созданием параметра и инициализацией кэша обязательно убедитесь, что автономные файлы синхронизированы с соответствующими сетевыми папками - не синхронизированные изменения будут потеряны и вы можете лишиться важных данных!
После перезагрузки компьютера кэш будет переинициализирован и ключ автоматически удалён.
Можно создать параметр автоматически через командную строку, выполнив следующую команду:
Посмотреть на каких узлах NUMA в многопроцессорных серверах работают виртуальные машины на сервере Hyper-V можно с помощью Системного монитора (Performance monitor), который находится в папке Администрирование. Запустите Системный монитор и добавьте все счетчики Hyper-V VM Vid Patrition как показано на скриншоте:
Переключитесь в режим просмотра Отчет (Report), в результате вы увидите следующую таблицу. В строке Preferred NUMA Node Index отображается номер узла NUMA, на котором работает та или иная виртуальная машина:
Иногда требуется, чтобы определенная виртуальная машина запускалась только на заданном узле NUMA. Это можно сделать с помощью сценария PowerShell. Подробнее читайте в этой статье.
Для настройки автоматического перенаправления при обращении к странице техподдержки с протокола http на https в продукте ServiceDesk Plus MSP компании ZOHO необходимо сделать следующее:
1) Изменить порт веб-сервера на 443. Для этого необходимо в командной строке из папки C:\ManageEngine\ServiceDeskPlus-MSP\bin запустить скрипт changeWebServerPort.bat с ключами 443 и https:
2) Зайти в папку C:\ManageEngine\ServiceDeskPlus-MSP\server\default\deploy\jbossweb-tomcat50.sar, найти файл server.xml и открыть его для редактирования (например, в wordpad).
3) Найти следующие строки и заменить значение 8080 на 80 и 8443 на 443:
<!-- A HTTP/1.1 Connector on port 8080 -->
<!-- The compression parameters are taken from the default Tomcat server.xml-->
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
compression="off"
compressionMinSize="2048"
setBodyEncodingForURI="true"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/plain"/>
4) Зайти в папку C:\ManageEngine\ServiceDeskPlus-MSP\applications\extracted\AdventNetServiceDesk.eear\AdventNetServiceDeskWC.ear\AdventNetServiceDesk.war\WEB-INF, найти файл web.xml и открыть его для редактирования (например, в wordpad).
Если вы используете аутентификацию в системе Windows на основе токенов Rutoken (или других токенов или смарткарт), например, для авторизации доступа к компьютеру, терминальному серверу (в общем, для авторизации входа в Windows), и на некоторых компьютерах она вдруг перестала работать и в окне аутентификации (Безопасность Windows) выдается ошибка "На этой смарт-карте не найдены действительные сертификаты" или "Действительные сертификаты не обнаружены", то возможно причина состоит в том, что на этот компьютер установили какое-либо стороннее криптографическое ПО, которое также может использоваться для авторизации входа в Windows, например, КриптоПРО CSP. Для решения проблемы необходимо отключить в этом стороннем криптографическом ПО поддержку авторизации входа в Windows. В случае КриптоПРО запустите оснастку КриптоПРО CSP, откройте вкладку Оборудование, далее Настроить типы носителей. В открывшемся окне найдите ваш тип носителя, в нашем случае это Rutoken, выберите его и нажмите Свойства. В открывшемся окне перейдите на вкладку Настройки и снимите галку "Для входа в Windows при помощи Rutoken использовать КриптоПРО CSP". После этого все снова начнет замечательно работать.
В Microsoft Windows Server 2012 и Windows 8 отсутствует возможность изменять тип сетевого подключения через Центр управления сетями и общим доступом (Network and Sharing Center). Если вам нужно изменить тип сети, это можно сделать следующими способами:
1. С помощью изменения в реестре:
Запустите regedit, найдите ключ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles. Этот ключ будет содержать профили сетей вида {93BCDFC1-5C66-420A-A786-85AFBCE1D5E8}, в фигурных скобках может быть любой другой номер - найдите среди них вашу сеть по ключу ProfileName (её имя отображается Центре управления сетями) и измените значение ключа Category в соответствии с тем типом сети, который вам нужен:
0 - Общественная сеть (Public Network)
1 - Частная сеть (Private Network)
2 - Доменная сеть (Domain Network)
2. С помощью изменения локальных политик безопасности:
Запустите оснастку Локальная политика безопасности (Local Security Policy). Это можно сделать в Панели управления, далее Система и безопасность -> Администрирование, либо просто выполнив в командной строке secpol.msc. Далее в левой части оснастки выбираете Политики диспетчера списка сетей (Network List Manager Policies), в результате справа отобразится список сетей. Найдите среди них вашу сеть по имени, которое отображается в Центре управления сетями, кликните на ней правой кнопкой мыши и зайдите в Свойства (Properties). Далее в закладке Имя сети (Network name) можно изменить соответственно имя сети, а в закладке Сетевое расположение (Network Location) - тип сети. Также можно изменить иконку сети. Если сервер или компьютер включены в домен, изменить тип сети на другой невозможно.