F T Y

Increasing the number of Windows sockets or ports

To resolve connection errors with an Oracle Essbase Server, increase the number of sockets or ports on the Microsoft Windows operating system that are available for program use by adding two entries in Microsoft Registry Editor.
Important: Use Microsoft Registry Editor at your own risk. Incorrect use may cause problems that require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly.

Procedure

  1. From the Windows Start menu, run the regedit application.
  2. In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters directory, create a new DWORD value namedMaxUserPort.
  3. Set the properties for MaxUserPort to use a value of 65534 and a base of Decimal.

    The range for value is from 30000 to 65534.

  4. In the same directory, add another DWORD value named TcpTimedWaitDelay.
  5. Set the properties for TcpTimedWaitDelay to use a value of 50 and a base of Decimal.

    The range for value is from 30 seconds to 300 seconds, with a default value of 240 seconds (4 minutes).

  6. After closing the regedit application, restart the Microsoft CRM server or restart your computer.

Results

For more information, visit the technet2.microsoft.com Web site and search on the terms MaxUserPort and TcpTimedWaitDelay.

 

 

Как исправить :
Для того чтобы Windows создала новый профиль нужно залезть в реестр:
HKLM\SOFTWARE\Microsoft\Windows NT\CorrentVersion\ProfileList \

там находим раздел вида S-1-5-21-/*много_цифр*/ в котором параметр ProfileImagePath
содержит логин пользователя для которого грузится только временный профиль и удаляем его (раздел целиком).

 

 

Упрощенная процедура междоменной миграции

Описанный в данной статье сценарий междоменной миграции объектов AD является квинтэссенцией руководств по миграции, представленных на ресурсах Microsoft. Многих системных администраторов отпугивает перенос объектов AD между лесами/доменами из-за громоздкости существующих руководств по данному процессу. В существующих публикациях раскрывается 100% возможностей средств Active Directory Migration Tool, немалая часть которых редко используется в реальных ситуациях, что и делает процесс подготовки к миграции долгим для многих администраторов, сталкивающихся с этим впервые. Классический сценарий требует избыточности в плане подготовки исходного и конечного доменов.

В представленном сценарии описывается процесс межлесовой миграции с минимальными вмешательствами в инфраструктуру исходного домена (например, без доверительных отношений), что несет в себе множество преимуществ. Перед выполнением данного сценария все же не стоит пренебрегать резервированием исходного и целевого доменов и созданием планов миграции и отката в исходную точку. Данная схема работает при минимальных логических изменениях в процессе для доменов любого уровня и на любых ОС, начиная с Windows Server 2000, в том числе и для Small Business Server’s и Essential Business Server’s.

В описываемом сценарии представлено два корневых домена под управлением ОС Windows Server 2008 SP2. Исходный домен SOURCE.LOCAL (FSMO-контроллером которого является сервер dc1.source.local, IP 10.8.2.251) содержит 158 пользователей и 8 групп безопасности, в которых они распределены. Конечный домен TARGET.LOCAL (dc2.target.local, IP 10.8.2.252). Цель – перенести все учетные записи пользователей (с сохранением паролей), группы безопасности и рабочие станции в конечный домен.

  1. Подготовка исходного домена заключается в настройке DNS-пересылок и отключении DHCP-сервера. Все существующие пересылки необходимо удалить и создать обычную пересылку, указывающую на контроллер целевого домена.

    1

    Причем нам необходимо, чтобы IP-адрес контроллера целевого домена ссылался на его имя в FQDN-формате, для чего нужно добавить соответствующую PTR-запись в обратную зону.

    Если же исходный домен-контроллер находится под управлением ОС Windows Server 2003, то можно ограничиться созданием пересылки на FQDN конечного домена без добавления в обратную зону PTR-записи контроллера конечного домена.

  2. Подготовка целевого домена состоит в создании conditional forwarder’а, задающего соответствие имени исходного домена SOURCE.LOCAL его контроллеру dc1.source.local и включении DHCP-сервера в конечном домене. Все существующие пересылки также необходимо удалить. Если есть возможность использовать DHCP-сервер на активном сетевом оборудовании, то лучше использовать его.
    2
    3

    Наличие PTR-записи исходного домен-контроллера в обратной зоне также является необходимым условием.

    Если целевой домен находится под управлением ОС Windows Server 2003, то в DNS достаточно ограничиться пересылкой на исходный домен по IP-адресу контроллера домена. В обратной зоне никаких изменений вносить не требуется при этом.

    4

  3. Пароли для администраторов доменов должны отличаться. Также в обоих доменах должны быть одинаковые групповые политики в отношении сложности паролей. На время миграции настоятельно рекомендуется отключить встроенные брэндмауэры на клиентских ПК. Соответственно, в конечном домене также должна быть активной политика, отключающая службы Windows Firewall и Internet Connection Sharing (ICS). Это может сильно повлиять на работу агента миграции клиентских ПК, который будет закачиваться на них и совершать необходимые операции.
  4. Перед началом процесса миграции все клиентские ПК должны быть включены и разлогинены. Никто не должен работать.
  5. Если в исходном домене находятся ПК под управлением ОС Windows XP, Windows 2000 или Windows Server 2003, а конечный домен находится под управлением контроллеров с ОС Windows Server 2008, то необходимо на всех контроллерах в целевом домене создать/изменить ключ в реестре:
    Registry path: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
    Registry value: AllowNT4Crypto
    Type: REG_DWORD
    Data: 1
  6. После создания пересылок необходимо установить средство ADMT на целевой контроллер в зависимости от версии ОС. Для Windows Server 2008 подходит только версия 3.1 (Active Directory Migration Tool version 3.1). Для всех остальных – любые вплоть до третьей (здесь мы намеренно не рассматривает вариант, когда целевой контроллер домена находится под управлением NT4). После установки средства ADMT на конечный сервер, необходимо узнать куда оно проинсталлировалось (вариантов несколько: от X:\Program Files (x86) до X:\WINDOWS). Необходим точный путь до файла оснастки migrator.msc.
  7. Создание командного файла для запуска оснастки средства ADMT migrator.bat (поскольку доверие между доменами, строго говоря, не является необходимым условием). migrator.bat должен содержать в себе следующую команду:
     
    Runas /Netonly /user:ИМЯ_ИСХОДНОГО_ДОМЕНА\ЛОГИН_АДМИНИСТРАТОРА "Mmc \"%windir%\ADMT\migrator.msc\""

    В нашем случае команда будет выглядеть так:

     
    Runas /Netonly /user:SOURCE\Administrator "Mmc \"%windir%\ADMT\migrator.msc\""

    Запускать командный файл придется каждый раз для запуска средства ADMT.

  8. В данном сценарии предполагается миграция существующих паролей. Для того, чтобы это осуществить необходимо проделать следующие шаги.
    1. Генерация ключа для исходного домена на целевом контроллере командой:
       
      Admt key /option:create /sourcedomain:ИМЯ_ИСХОДНОГО_ДОМЕНА /keyfile:ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ /keypassword:ПАРОЛЬ_УДОВЛЕТВОРЯЮЩИЙ_ПОЛИТИКЕ ПАРОЛЕЙ_В_ОБОИХ_ДОМЕНАХ

      В нашем случае команда генерации ключа будет выглядеть так:

       
      Admt key /option:create /sourcedomain:SOURCE.LOCAL /keyfile:C:\PWD.pes /keypassword:{microsoftkey777}
    2. Импортирование ключа для исходного домена на целевом контроллере командой:
       
      admt key /option:import /sourcedomain: ИМЯ_ИСХОДНОГО_ДОМЕНА
      /keyfile: ПОЛНЫЙ_ПУТЬ_К_КЛЮЧЕВОМУ_ФАЙЛУ
      / keypassword:ЗАДАННЫЙ_РАНЕЕ_ПАРОЛЬ

      В нашем случае импортирование созданного ранее ключа будет выглядеть так:

       
      admt key /option:import /sourcedomain:source.local /keyfile:C:\PWD.pes /keypassword:{microsoftkey777}
    3. Размещение полученного ключа локально на исходном контроллере.
    4. Установка средства Password Export Server version 3.1 (ADMT Password Migration DLL) на исходный контроллер. При установке будет запрошен ключевой файл, на который надо указать и ввести указанный выше пароль. После установки следует перегрузить сервер.
    5. Установка разрешений на запуск службы Password Export Server Service. Для этого необходимо в обоих доменах завести пользователей с одинаковыми логинами и паролями. В нашем случае это пользователь PES с правами обычного доменного пользователя. Служба должна запускаться от имени созданного пользователя. После установки разрешений службу можно запустить. Начиная с этого момента, возможна миграция существующих паролей в целевой домен.
      Следует отметить, что метод миграции паролей с помощью средства Password Export Server работает только с ОС Windows Server 2003 и 2008. Если исходный домен находится под управлением более ранней ОС, то следует обратиться к соответствующему разделу мануала по ранним версиям ADMT.
  9. Начало миграции. Для запуска средства ADMT используем созданный ранее командный файл. При запуске будет запрошен пароль администратора исходного домена.
    1. Для миграция учетных записей пользователей необходимо запустить User Account Migration Wizard из меню Action. Далее необходимо ввести информацию об исходном и целевом доменах, указав при этом именно те контроллеры, которые были использованы при создании DNS-пересылок. В нашем случае это dc1.source.local и dc2.target.local. После выборки необходимых пользователей из исходного домена необходимо указать контейнер в целевом домене для размещения мигрированных объектов. Далее отмечаем опции Migrate PasswordsDo not update passwords for existing users и вводим контроллер исходного домена, на котором запущена служба PESSVC, в поле Password migration source dc. В нашем случае это dc1.source.local. В меню Account Transition Options отмечаем опции Target same as source и Migrate user SIDs to target domain. Далее будет предложено включить аудит учетных записей в исходном домене. Следует согласиться со всеми предложениями, после чего перезагрузка исходного контроллера будет необратима. После загрузки исходного контроллера необходимо запустить на нём службу PESSVC и продолжить миграцию учетных записей пользователей на конечном сервере. После чего необходимо ввести логин и пароль администратора исходного домена. В меню User Options отметить опции Translate roaming profilesUpdate User RightsFix users’s group membership. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. С конфликтующими объектами лучше разобраться вручную. Меню с выбором исключений можно пропустить. Следует отметить, что в данном сценарии вместе с учетными записями пользователей также мигрируются перемещаемые профили, что делает данный процесс незаметным для конечного пользователя. Если в домене не используются перемещаемые профили, то рекомендуется заведомо их сделать таковыми.
    2. Для миграции групп безопасности необходимо запустить Group Account Migration Wizard из меню Action. Далее необходимо ввести информацию об исходном и целевом доменах, указав при этом именно те контроллеры, которые были использованы при создании DNS-пересылок. В нашем случае это dc1.source.local и dc2.target.local. После выборки необходимых групп безопасности из исходного домена необходимо указать контейнер в целевом домене для размещения мигрированных объектов. В меню Group Options необходимо отметить опции Update user rightsFix membership of groupMigrate group SIDs to target domain. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. Меню с выбором исключений можно пропустить. Никогда не следует выполнять миграцию таких глобальных групп безопасности как «Издатели сертификатов», «Администраторы DHCP», «Пользователи DHCP», DnsAdmins, DnsUpdateProxy, «Администраторы домена», «Компьютеры домена», «Контроллеры домена», «Гости домена», «Пользо¬ватели домена», «Администраторы предприятия», «Владельцы-создатели групповой политики», «Серверы RAS и IAS», «Администраторы схемы» и «Пользователи WINS» и их аналоги.
    3. Миграция рабочих станций осуществляется через Computer Migration Wizard меню Action. Дойдя до меню Translate Objects можно отметить те опции, которые нам необходимы, после чего в Security Translation Options выбрать опцию Add (Add equivalent security references for target objects and have source reference intact). В следующем окне необходимо выставить временную задержку, по истечении которой клиентский ПК будет перезагружен (при условии, что агент мигрирования завершится успешно). Меню с исключениями можно пропустить. В меню Conflict Management отметить опцию Do not migrate source objects if a conflict is detected in the target domain. После того, как работа мастера завершится, будет запущено диалоговое окно управления агентами миграции ПК с перечнем всех выбранных ранее ПК, подлежащих переносу в новый домен. В разделе Agent Actions следует отметить опцию Run pre-check and agent operation и нажать Start. Со временем агент начнет перегружать клиентские ПК и выполнять процедуру POST-CHECK, которая может завершаться с ошибкой, если перед миграцией не были корректно настроены службы DHCP в обоих доменах. Чаще всего это свидетельствует о том, что клиентский ПК не получил корректных настроек от DHCP-сервера в конечном домене. По статистике примерно на 100 рабочих станций приходится 10-15, которые не обрабатываются агентом миграции. Такие ПК придется переносить вручную, если сходу не попытаться устранить проблему, которая, скорее всего, кроется в службах Workstation, Netlogon и RPC.
  10. По завершении миграции необходимо вернуть обратно удаленные ранее пересылки на обоих контроллерах, удалив при этом служебные (созданные для 

 

Пятница, 15 мая 2015 06:00

Комманды службы времени windows

 

w32tm /query /source - выводит источник времени, на который настроена служба Windows Time
w32tm /monitor - при запуске на контроллере домена (КД) показывает, насколько отличается время на других КД и на внешнем источнике времени, на который настроен PDC
w32tm /config /syncfromflags:manual /manualpeerlist:ru.pool.ntp.org - настройка в качестве источника времени пула ntp-серверов ru.pool.ntp.org
w32tm /config /update - эту команду необходимо выполнить, чтобы служба времени применила новые настройки
w32tm /resync - выполнение синхронизации времени
w32tm /unregister - отменяет регистрацию службы и удаляет настройки из реестра
w32tm /register - регистрирует службу и восстанавливает настройки по умолчанию 

 

 В операционных системах Windows Vista, Server 2008 и Windows 7, Microsoft по умолчанию включает поддержку IPv6 (Internet Protocol Version 6). IPv6 - новый сетевой протокол адресации рано или поздно заменит IPv4, который в настоящее время является самым популярным стандартом. Если в вашей сети нет определенных требований для использования протокола IPv6, что бывает очень редко, то есть смысл отключить IPv6. В отличие от других протоколов, вы не можете отключить IPv6, просто отключая протокол на каждом из Ваших сетевых интерфейсов. Если это сделать таким образом, то можно получить определенные проблемы с приложениями, которые используют loopback и интерфейсное тунелирование. Правильным способом отключения протокола Ipv6 является деактивация его через системный реестр.


Для начала запустим редактор реестра: «Win+R» вводим regedit. Переходим в веткку:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters

Здесь создаем новый параметр, для этого делаем правый клик на разделе Parameters и в контекстном меню выбираем «Создать» -> «Параметр DWORD (32-бита)». Задаем имя этому параметру – DisabledComponents. Теперь делаем двойной клик левой кнопкой на вновь созданном параметре, и устанавливаем значение FF.

После перезагрузки IPv6 будет отключен на всех интерфейсах.
Страница 5 из 5

Все права защищены. Перепечатка материалов без активной ссылки запрещена.

ИП «Жаинбаев Е.Г.», свидетельство о регистрации № 0004274, серия 0101