Tagebuch

Понадобилось вчера заняться некромантией, делаю себе заметку.
В общем, этот сканер даже не подозревает о существовании 64-битной win7. Алгоритм действий таков:

1. Скачать дрова на Canonscan Lide 60 под win7x64 с офф сайта.
2. Установить дрова.
3. Подсунуть через диспетчер устройств обнаруженному сканеру дрова от Canon для Lide60.
4. Установить Canoscan Toolbox версию 4.932 (более ранние не видят этот сканер).
5. Привязать сканер через настройки (он там ессно lide 60).
6. В качестве программы для вывода изображения указать exe-шник этого самого toolbox.

Ну и пункт 7 - выкинуть этого динозавра и купить себе нормальный сканер.

Долго не хотела обновлять скайп на это новое говно, потом решила, что терять уже нечего, все равно рано или поздно придётся.
Охренела сразу - теперь по дефолту врублено форматирование текста. Если ты берёшь текст в звёздочки, текст становится жирным. Ну и ещё несколько таких же фич. Отключить красивой галочкой нельзя.

Кто не понял - в новом "красивеньком" скайпе вы пишете *сообщение*, в чат улетает сообщение.

Пошла гуглить, можно ли это отключить как-то альтернативно. Таки можно!

Способа два:

1. Локальный.
Перед каждым сообщением, где не нужно форматирование, ставить две собаки - @@.

2. Глобальный.
Ввести в любой чат следующую команду:
/setupkey *Lib/Conversation/EnableWiki 0

Ещё куча ключей есть тут.

Как говорится, хочешь сделать человеку хорошо - сделай плохо, а потом верни, как было. Мне хорошо:)

Подняла вчера очередной exchange edge, синхронизация прошла и тут бряк - знакомая ошибка. В очереди скапливаются письма, отлуп:
451.4.4.0 Primary target IP address responded with: "451.5.7.3 cannot achieve exchange server authentication.

Ну, собственно, оно нам прямым текстом говорит "потуши файрвол, сука". А если точнее - требуется отключить SMTP Inspection на cisco.

В конфигурации lync 2013 2 front-end + edge обнаружилась проблема - нет подключения к мобильным клиентам.

На десктопных клиентах вне сети с рутовым сертификатом всё в порядке. Мобильные при попытке авторизоваться уходили в бесконечный цикл и радостно отваливались.

Lync connectivity analyzer утверждал что:
Cookie  found in autodiscover response: StatusCode: 401, ReasonPhrase: 'Unauthorized', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
После чего через некоторое время тоже отваливался (хочу найти того, кто не сделал там возможности остановить процесс и оторвать ему кривые руки).
Коллега ругался в сторону названия пула - с суффиксом lan, весь интернет как один человек утверждал, что дело в wildcard. При этом некоторое время назад у меня всё работало.

Решение нашла следующее:

1. Вернула корректные настройки аутентификации на IIS (кто правил - найду убью). А именно, на фронтендах, Lync external web site, WebTicket, authontication - Анонимус enabled, windows enabled.
2. Удалила левые сертификаты на EDGE, добавила актуальные корректно через мастера Lync (тут шаманизм уже сугубо индивидуальный).
3. На фронтендах проверила Get-CsWebServiceConfiguration, удивилась. Дальше понятно:
Set-CsWebServiceConfiguration –UseWindowsAuth Negotiate (опять же из серии кто отменил?).

Взлетело.

#Вообще к lync больше всего подходит определение "сраный звездолёт".

Пользователь пожаловался, что будучи владельцем группы, не может редактировать членство группы через outlook.
Отлуп получает следующий:
Не удается сохранить изменения состава общей группы. Недостаточно прав доступа для выполнения операции над объектом.

Exchange shell:
Get-ManagementRoleAssignment
Обнаруживаем отсутствие роли mydistributiongroupmembership

Добавляем:
New-ManagementRoleAssignment -Role mydistributiongroupmembership -Policy "Default Role Assignment Policy"

Профит.

В сети полно мануалов по кросс-форест миграции, а это для моей записной книжки.
Уровень леса и там и там 2008r2, exchange 2010.

1. В target лесу делаем Prepare-move-request
Синтаксис:

$local =Get-Credential - таргет
$remote =Get-Credential - исходный
C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\Prepare-MoveRequest.ps1 -Identity user@domain.com -RemoteForestDomainController dc.sourcedomain.com -RemoteForestCredential $remote -LocalForestDomainController dc.targetdomain.com -LocalForestCredential $local -UseLocalObject -Overwrite -verbose

2. Запускаем ADMT
Миграция пользователя.
User account migration wizard – source domain, target domain
User selection option – select users from domain
User selection – добавляем выбранного пользователя
Organization unit selection – выбираем нужное ou
Password options – Migrate passwords – Password migration source DC DC with PES
Account Translation Options – Target Account State – Target same as source, Sourse account disabling оставляем пустым. Обязательно ставим галку Migrate user SIDs to target domain.
На запрос аудита отвечаем YES (если не включили политику)
User account - Вводим логин-пароль администратора исходного домена
User options – Translate roaming profiles – Update user rights – Fix users group memberships
Exclude specific object properties from migration. Выбрать и исключить (тип user):

HomeMDB
HomeMTA
mDBUseDefaults
msExchHomeServerName
msExchMailboxSecurityDescriptor
msExchMDBRulesQuota
msExchPoliciesIncluded
msExchRecipientDisplayType
msExchRecipientTypeDetails
msExchUserAccountControl
msExchVersion
showInAddressBook

Conflict Management – Migrate and merge conflicting objects – отметить move merged object to the specified target Organization unit
Finish

3. Перемещаем локальный профиль.
Security Translation Wizard
Previosly migrated objects
Sourse domain, target domain
Select computers from domain
Add – выбрать компьютер
Translate objects – user profiles
Security Translation Options – add
Finish
В появившемся окне нажать run pre-check and agent operation

4. Move-request. Выполняется в целевом домене. Синтаксис следующий:
New-MoveRequest -Identity user@domain.lan -Remote -TargetDatabase databasename -RemoteHostName cas.sourcedomain.lan -RemoteCredential

$remote -TargetDeliveryDomain stg.ru -DomainController dc.target.lan


Дополнения

Проверить, что SID-хистори перенеслась после миграции пользователя, можно либо просмотрев лог ADMT, либо посмотрев атрибут sIDHistory у

пользователя в перенесённом домене. Атрибут не должен быть пустым.

При выполнении prepare-moverequest можно получить следующее:
ould not find the default Administrative Group 'Exchange Administrative Group (FYDIBOHF23SPDLT)'.
+ CategoryInfo : NotSpecified: (0:Int32) [Update-Recipient], DefaultAdminist...tFoundException
+ FullyQualifiedErrorId : 27C11212,Microsoft.Exchange.Management.RecipientTasks.UpdateRecipient

В этом случае у нас не пройдет Invoke Update-Recipient, следовательно, атрибут legacyExchangeDN не будет установлен. При попытке сделать move-request получим отлуп:  critical property 'LegacyExchangeDN' is missing in the UserMailbox object

В этом случае либо делать самому Update-Recipient, либо прописывать LegacyExchangeDN вручную.

Если при попытке сделать move-request получаем:
The target recipient user' must be a mail-enabled user when the primary mailbox is moving cross forest.
+ CategoryInfo : InvalidArgument: (user@domain.com:MailboxOrMailUserIdParameter) [New-MoveRequest], RecipientTaskException
+ FullyQualifiedErrorId : CBF0E63A,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

Значит в ADMT не были исключены определённые атрибуты. Смотрим пользователю в атрибуты, атрибут msExchHomeServerName. Если там ссылка на MBX-сервер из старого домена, значит так и есть. Удаляем атрибут, запускаем заново. После того, как пройдет move-request, в msExchHomeServerName появится имя нового сервера.

Если вы по какой-то причине сначала сделали переезд ADMT до prepare-move request, при попытке выполнить prepare получите следующую ошибку:
Cannot create mail enabled user because an existing object with type already has the same proxy addresses/MasterAccountSid

В этом случае вам придётся прибить всё из атрибута proxyAddresses и сделать учетку mail-enabled:
Enable-MailUser -DomainController dc.domain.lan -Identity user
ExternalEmailAddress – user@target.local, дополнительно proxyaddress user@domain.com
В исходном домене учетке сделать дополнительный proxyaddress user@target.local

После этого осуществить prepare-moverequest, где в качестве user необходимо написать user@target.local
Дальше move-request – как обычно.

Собственно, всё.

При попытке удалить отключенную и якобы пустую датабазу можно получить следующий отлуп:

This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, or arbitration mailboxes.

При этом на Get-Mailbox -Database databasename мы ничего не получим.

Логично предположить, что сначала:

Get-Mailbox -Database databasename -Arbitration

На это получаем:

SystemMailbox{1f05a927... SystemMailbox{1f0... databasename unlimited
FederatedEmail.4c1f4d8... FederatedEmail.4c... databasename 1 MB (1,048,576 bytes)
SystemMailbox{e0dc1c29... SystemMailbox{e0d... databasename unlimited

Дальше всё ещё логичнее:

Get-Mailbox -Arbitration -Database databasename | New-MoveRequest -TargetDatabase databasename2

Как переименовать VMDK

1. Edit settings виртуальной машины, к которой присоединён vmdk. Удалить диск.
2. По ssh к выбранному хосту.
3. До директории с выбранным vmdk - cd /vmfs/volumes/DatastoreName/. Чтобы просмотреть всё содержимое директории - ls
4. vmkfstools -E oldname.vmdk newname.vmdk

Обращайте внимание на необходимость соблюдать регистр. Команда -e и команда -E это две разные команды.

В очередной раз себе на заметку.

Конфигурация:

esxi 5.5 + vCenter + cisco + лезвия по 6 портов.
Со стороны каждого лезвия по три стандартных свитча - Management, vMotion с FT и VM. На каждом свитче по 2 сетевых интерфейса.
Задача - включить LACP для Management и vMotion

vSphere поддерживает LACP только при использование distributed switch. При этом 5.5. позволяет настроить LACP только из веб-клиента. D-свитч можно сделать и через обычного клиента, но работать LACP там не будет.

Последовательность действий следующая (про циски я скажу только что там интерфейс в актив):

1. Веб клиент => home => networking => action => new distributed switch

2. В мастере => имя => выбор версии => 5.5 => количество аплинков в нашем случае 2 => имя первой дефолтной порт=>группы => готово. Первая группа будет отвечать за менеджмент.

3. Заходим в свежесозданный свитч => manage => LACP => зелёный крестик New Link Aggregation Group => имя, количество портов, режим в зависимости от настроек на циске, если на циске актив, здесь пассив, тип балансировки. Ок, создали.

4. Оттуда же => action => add and manage hosts => add host and manage host networking => new hosts => выбираем хосты => Select network adapter tasks => Отмечаем Manage physycal adapters, Manage VMcernel adapters.

5. Страница менеджмента физическими адаптерами. В нашей конфигурации все адаптеры должны быть отмечены как "on other switches". Выбираем те два vmnic, которые относятся к менеджменту. Выделяем один => assign uplink => выбираем созданный LAG, выбираем LAG-0. Аналогично со вторым интерфейсом, только LAG-1.

6. Страница управления VMkernel адаптерами. Выбираем имеющиеся и находящиеся сейчас в другом свиче, ассоциируем с группой, созданной на шаге 2. Далее-далее => происходит миграция.

7. Action => manage distribution port groups => выбираем teaming and failover => выбираем группу, созданную на втором шаге => на странице тиминга добавляем созданный LAG в актив, аплинки в unused.

8. Проводим те же самые действия для создания LAG на VM.

9. Из свича => action => Migrate VM to another network => указать исходную и целевую сеть => переехать.

10. Посмотреть на результаты можно из свича => topology

#Ненавижу веб-консоли.

Столкнулась с проблемой - HP блейд с FlexFabric 10Gb 2-port 534FLB Adapter на борту отказывается стучать в 3par, соответственно в консоли 3par нет доступных WWN.

Выяснилось, что в дистрибутиве vmware 5.5 под HP нет всех драйверов под этот адаптер. По какой логике вообще размещаются дрова я хз.
Драйвера нашлись тут.
Устанавливала через компонент update manager и импорт патча.
Другие способы установки драйверов можно посмотреть тут.
В принципе по-моему проще через консоль, например так: esxcli software vib install –d /vmfs/volumes/datastore/drv.zip
Естественно перед установкой драйверов надо перевести ноду в maintenance mode.

Потом требуется их включить через shell:

esxcli fcoe nic list - список доступных адаптеров.

esxcli fcoe nic discover -n vmnic* - активация адаптера.

esxcli fcoe adapter list - просмотр.

Заодно удалось выяснить, что на сайте HP в редкой статье нет косяков с синтаксисом. Ну и так по мелочи, например exception:exception в случае подсовывания просто vib меня несколько удивил.