Начальная разборка устройства не представляет сложностей, затем снимаем крышку отсека радиомодуля и видим:

Нда... Видим мы печальную картину: чипсет охлаждается при помощи крышки отсека радиомодуля через теплопроводную подложку высотой 2мм, при этом сама подложка закрывает только половину чипсета. Про чипы памяти, находящиеся при этом в «безвыходной бане», даже не хочется думать. Ведь, если пластиковый корпус устройства так ощутимо греется, что же происходит внутри «бани»?

Ладно, оставим эти размышления потомкам, а сами возьмем два радиатора, ножницы, термопасту, пузырек суперклея и решим проблему охлаждения так, чтобы она более не мешала спать по ночам.

Хотя это и широко анонсировалось, до сих пор мало кто хорошо знает об одной интересной особенности новых операционных систем от компании Microsoft. Я о поддержке режима работы в качестве точки доступа, который появился в Windows 7 и Server 2008 R2.
Уж скажем честно, решение, традиционно, получилось чуть-чуть не совсем доработанным до того функционала, о котором можно было мечтать. Но для целей оперативно предоставить доступ в интернет приехавшему на переговоры партнеру — вполне подойдет, когда не хочется этого партнера заставлять мучительно ожидать организации доступа силами сотрудников ИТ отдела.
Достаточно лишь запустить командную строку с повышенными правами и скопировать-вставить в появившееся черное окно две строки:

1. netsh wlan set hostednetwork mode=allow ssid=LibertineGuest key=superKey^1234
2. netsh wlan start hostednetwork

После чего вызвать свойства своего текущего сетевого подключения и на вкладке «доступ» установить галочку «другие пользователи могут подключаться».
Вот и все, скучающий бизнес-партнер теперь может подключиться к беспроводной сети LibertineGuest используя пароль superKey^1234
Кстати, вот после этого имеет смысл задуматься о степени сетевой безопасности и том, за что же Вы все же платите сотрудникам своего ИТ отдела, утверждающим, что трудятся в поте лица, защищая корпоративные данные? Кто, кроме Вас, может проделать вышеозначенные операции и дать доступ группе злоумышленников сидящих в автомобиле внизу? А ведь, по-хорошему, у вас, как обычного пользователя, не должно было быть даже прав в системе на подобные операции.

Ну да ладно, предположим, мы все же используем технологии во благо
Итак, как я уже упомянул, в Server 2008 R2 появилась возможность создания беспроводной точки доступа. А, значит, если у нас есть все необходимые лицензии на использование соответствующего ПО, мы вполне можем установить на него Threat Management Gateway со всем его приятным функционалом в виде защиты от внешних угроз, кэширования и антивирусной проверке трафика, возможности создания VPN подключений и, главное, автоматического переключения на резервный канал при недоступности основного (например, то же коммерческий публичный WiFi).
Правда, кое о чем необходимо упомянуть:

1. По умолчанию, поддержка беспроводных подключений в серверной OC отключена. Поэтому, необходимо перевести в автоматический старт службу «Wireless LAN AutoConfig»
2. После перезагрузки системы необходимо заново вручную выполнить команду «netsh wlan start hostednetwork». Но это решается крайне просто, учитывая, что для запуска при помощи ключа реестра или локальной групповой политики не активен UAC (на самом деле, оно неактивно для всех действий учетной записи системы, но это детали).
3. Поскольку все данное решение разработано производителем именно для целей «быстрого подключения партнера», при старте сети будут включены и запущены службы ICS (общий доступ к подключениям) и DHCP/DNS сервер. Что, разумеется, вызовет конфликт со службами TMG. Что ж, просто необходимо сначала все ненужные службы остановить и запретить к запуску (т.к., в частности, ICS будет пытаться сделать перезапуск при любой остановке), а затем все нужные нам службы — перезапустить. Все это ровно также просто автоматизируется, главное, помнить о том, что необходимо вставлять задержки выполнения, т.к. некоторые службы, имеющие под собой зависимые, требуют некоторого времени на старт

Домашнее же применение описанного решения (за исключением серверной ОС и TMG, т.к. воровать нехорошо, если можно использовать вполне легальные и легко настраиваемые решения внутри виртуальной машины на которую проброшено сетевое подключение) может выглядеть так:

Существует несколько недорогих программных решений для учета потребления расходных материалов. Но дело в том, что по большому счету, они являются излишне функциональными. Как правило, необходимо не иметь полную копию всех распечатанных документов, а лишь видеть статистику по количеству отпечатков на каждом принтере с распределением по пользователям.

И снова нам на помощь приходит простое и функциональное средство LogParser (ранее примеренное для анализа логов Exhange2007), на этот раз используемое для анализа логов принт-сервера.

Итак, предположим, нам необходимо получить простой csv файл, где будет присутствовать информация за сегодняшний день о том, когда, кто, на каком принтере и сколько страниц распечатал. Да и название отправленного на печать документа лишним не будет.
Для этого к командной строке нам необходимо написать:
1. LogParser.exe — без комментариев
2. file:parsprn.sql  — файл, в котором записан необходимый SQL запрос
3. -i:EVT — указатель, что ввод необходимо взять из системного лога принт-сервера
4. -o:CSV — указатель на необходимый формат вывода

Но прежде, чем выполнять команду, неплохо будет создать сам файл запроса parsprn.sql:
select
TimeGenerated AS LogonDate,
EXTRACT_TOKEN (Strings, -6, '|') AS docname, — из за того, что в имени файла могут встречаться символы |, рекомендую использовать именно «обратную» форму записи.
EXTRACT_TOKEN (Strings, -5, '|') AS username,
EXTRACT_TOKEN (Strings, -4, '|') AS prndevice,
EXTRACT_TOKEN (Strings, -2, '|') AS bytesize,
EXTRACT_TOKEN (Strings, -1, '|') AS pgsize
into v:\parsprn.csv
from SYSTEM — указатель, из какого именно системного лога нам необходимо извлечь данные
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM-dd'),'yyyy-MM-dd') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM-dd'),'yyyy-MM-dd') — на каком-то этапе была выявлена неприятная особенность определения понятия «сегодня», поэтому надежнее сравнивать простые строки
and EventID IN (10)

Отчет для целей архивного хранения мы таким образом получили. А теперь предлагаю начать создавать отчеты, приемлемые для восприятия человеком.
Первым делом, предлагаю не уходить далеко от простейшего отчета в виде csv файла, но вывести в него только события, имевшие место после завершения рабочего дня. Очень, кстати, забавно наблюдать реакцию, утверждающего что месячный отчет для вас он героически готовил вчера аж до 11 вечера, когда этому «герою» задаешь вопрос, как же так получается, если единственную копию он распечатал в 18:23?
Особенных изменения предыдущий вариант файла SQL запроса не потребует, всего лишь нужно добавить условие отбора:
and TO_TIMESTAMP (TO_STRING (TimeGenerated, 'h'),'h') > TO_TIMESTAMP (TO_STRING ('17'),'h')

Теперь предлагаю наглядно вывести, так сколько же отпечатков суммарно выводится на каждом из принтеров. Данная информация, кстати, может послужить хорошим аргументом в планировании модернизации оборудования. Вовсе не факт, что тому или иному департаменту действительно актуален апгрейд многофункционального устройства, а не установка дополнительного дешевого копира.
Примерная строка запуска будет выглядеть следующим образом:
LogParser file:parsprnpcountd.sql -i:EVT -o:CHART -chartType:barstacked -chartTitle:"printers by pages" -groupSize:1024×1600
parsprnpcountd.sql

Файл же непосредственно SQL запроса, примерно так:
select
EXTRACT_TOKEN (Strings, -4, '|') AS prndevice,
sum (TO_INT (EXTRACT_TOKEN (Strings, -1, '|'))) AS pgcount
into v:\pages_per_device.gif
from SYSTEM
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM-dd'),'yyyy-MM-dd') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM-dd'),'yyyy-MM-dd')
and EventID IN (10)
group by prndevice
order by pgcount desc

На выходе мы получим вполне наглядное представление того, что хотели выяснить:

Наконец, предлагаю вывести 25 «рекордсменов» по расходу бумаги. Примерная строка запуска запроса будет выглядеть следующим образом:
LogParser file:parsprnpcountopu.sql -i:EVT -o:CHART -chartType:barstacked -chartTitle:"top 25 users by pages" -groupSize:1024×800

Сам же файл запроса parsprnpcountopu.sql будет выглядеть следующим образом:
select
top 25 EXTRACT_TOKEN (Strings, -5, '|') AS username, — соответственно, если из запроса убрать «top 25», мы получим отчет, включающий всех пользователей
sum (TO_INT (EXTRACT_TOKEN (Strings, -1, '|'))) AS pgcount
into v:\top_users_by_pages.gif
from SYSTEM
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM-dd'),'yyyy-MM-dd') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM-dd'),'yyyy-MM-dd')
and EventID IN (10)
group by username
order by pgcount desc

Примерный вид получившегося отчета будет таков:

Ровно аналогичные отчеты можно, разумеется, получить и за другие промежутки времени. Все зависит исключительно от буйности фантазии. Например, запрос распределения количества отпечатков по дням будет выглядеть следующим образом:
select
TO_STRING (TimeGenerated, 'dd') as day,
sum (TO_INT (EXTRACT_TOKEN (Strings, -1, '|'))) AS pgcount
into v:\pages_per_day_month.gif
from SYSTEM
where
TO_TIMESTAMP (TO_STRING (TimeGenerated, 'yyyy-MM'),'yyyy-MM') = TO_TIMESTAMP (TO_STRING (SYSTEM_TIMESTAMP (),'yyyy-MM'),'yyyy-MM')
and EventID IN (10)
group by day
order by day

Связка Exchange и Outlook вполне разумно, что уже давно используется исключительно в двух вариациях: со включенной функцией кэширования и с выключенной. Оба варианта использования имеют свои недостатки: при выключенном кэшировании возникает излишняя нагрузка на сервер, а при включенном кэшировании объемного ящика — могут быть серьезные проблемы с производительностью на стороне клиента (в особенности, если на стороне клиента активизирован плагин для антивирусной проверки корреспонденции). Это, кстати, тот самый вариант, когда Best Practices поставщика оказываются малопригодны в конкретной рабочей среде.

Но иногда проявляются решения, казалось бы, давно устаревшие и не использующиеся. Например, по странному желанию и привычке, у конечного пользователя почтовый ящик Exchange подключен таким образом, что корреспонденция хранится в единственном экземпляре в локальных личных папках. Такой режим доступа правильно называется Remote Mail (средство удаленного доступа) и специально предназначен для того, чтобы при использовании низко скоростного удаленного соединения синхронизировать только папку Входящие с файлом личных папок. Соответственно, у конечного пользователя, который по неким личным причинам предпочитает хранить всю корреспонденцию в файле личных папок, возникает следующая сложность: входящая корреспонденция успешно помечается серверным антиспам фильтром и помещается в папку нежелательной корреспонденции почтового ящика.

Таким образом, со стороны конечного пользователя возникает недопонимание происходящего: растет устойчивое ощущение того, что часть входящей почты теряется, так как что видимая ему папка «нежелательная почта» (Junk mail) столь же пуста, сколь и папка входящих.

А решается, данная проблема недопонимания, собственно, единственным способом: необходимо выключить фильтрацию нежелательной корреспонденции для данного почтового ящика. Для этого достаточно выполнить следующую команду Exchange Management Shell:
set-Mailbox -Identity infobox@libertine.su -SCLJunkEnabled:$false

При этом Outlook конечного пользователя в момент получения с сервера новой корреспонденции успешно разместит всю нежелательную почту в соответствующей папке локального хранилища сообщений.

1. Отказ от необходимости создания кластера на уровне ОС. И я бы даже сказал, что производитель очень навязчиво декларирует данный факт. Кстати, да. Учитывая требования к оборудованию (а точнее, к системе хранения данных) для создания кластерных конфигураций на базе server 2008, лично для меня подобная необходимость была бы достаточно неприятна.
2. Возможность размещения любых дополнительных ролей Exchange на любой из нод отказоустойчивого почтового хранилища.

Но дело в том, что на самом деле отказоустойчивый кластер создается. Просто не на уровне операционной системы. А размещение на хранилище дополнительных ролей вовсе на так однозначно. Что все это значит? Рассмотрим дальше.

1. На два сервера объединенные в кластер была установлена роль mailbox store. При этом один из серверов мог быть заведомо слабее, т.к. выполнял исключительно функцию аварийного резерва.
2. Роли транспортного сервера и сервера клиентского доступа были установлены на единственный сервер, защищенный от аппаратных сбоев путем помещения внутри отказоустойчивой виртуальной машины.
3. Для защиты от вирусов и спама, был установлен отдельный релей на базе свободного ПО. Данное решение значительно снижает нагрузку на транспортный сервер Exchange, не требуя при этом дополнительных лицензий для сервера с ролью Edge Transport.
4. Для защиты от DDoS атаки на сервер клиентского доступа, данный сервер был опубликован через ISA сервер. Что, кстати, дополнительно значительно снижает нагрузку за счет кэширования и возможности отключения шифрования между внутренним интерфейсом ISA и интерфейсом CAS сервера (разумеется, нешифрованный трафик между серверами категорически рекомендуется передавать исключительно через выделенный VLAN).

1. Абсолютно все подключения теперь будут проходить через CAS сервер. Что автоматически означает необходимость его существенной производительности.
2. Размещение дополнительных ролей на одном из серверов хранилища почтовых ящиков — это замечательно (особенно, когда есть запас производительности). Но необходимо хорошо себе представлять тот факт, что в этом случае необходимо размещение тех же самых ролей на любом другом сервере и создания NLB кластеров для получения отказоустойчивости. Надеюсь, как работает NLB unicast и в чем особенность NLB multicast при доступе к нему через роутер, все хорошо понимают и недоразумений при настройке ни у кого возникать не будет
3. Поскольку, как я уже отметил, отказоустойчивый кластер на самом деле создается, честь и хвала тому, что сможет на тех же самых нодах поднять NLB. Да, признаю, в предыдущем пункте я именно издевался, разглагольствуя о режимах работы NLB
4. Да, есть одна особенность: при двух серверах с ролью транспорта, почта между двумя ящиками одной почтовой базы всегда будет доставляться через второй сервер транспорта — это особенность новой архитектуры и ее необходимо иметь в виду. Транспорт совершит локальную доставку только в случае недоступности стороннего партнера, и что-то мне подсказывает, что доступность проверяется отнюдь не запросом к smtp порту, а обычным icmp. Надеюсь, система контроля статуса критических сервисов всех серверов настроена у всех?
5. Резервное копирование и удобство восстановления лучше даже не упоминать, если совершенно случайно нигде не завалялось лицензии на DPM (Data Protection Manager). Впрочем, возможность создания «отсроченной» (lagged database) копии средствами самого Exchange, несомненно, существенно снимает ряд проблем.

Для начала, получим список всех существующих почтовых ящиков для перемещенных пользователей. Для этого запустим Exchange Management Shell (PowerShell) и выполним простенькую команду:
get-mailbox -organizationalUnit «libertine.su/Disabled Users»

По сути, нам это не дало ничего нового. Кроме того, что всего лишь перенаправив вывод данной команды на вход следующей, мы можем моментально решить вопрос с адресной книгой.
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | set-Mailbox HiddenFromAddressListsEnabled:$true
Все, мы только что отключили отображение в адресной книге имен всех пользователей, перемещенных в OU Disabled Users.

Теперь осталось понять, можем ли мы как-то сократить количество ящиков, занимающих место в почтовом хранилище.
Но для начала, выведем список всех учетных записей, имеющих доступ к ящикам в заданном контейнере:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Get-MailboxPermission | Format-List
Предупреждаю, на выходе будет очень длинная простыня Поэтому, вывод целесообразно было бы перенаправить в тестовый файл и далее работать уже с ним.

Поскольку нам нет резона тратить массу времени на тщательную вычитку доступов для каждого ящика, целесообразно выбрать любой и на его основе написать фильтр, существенно облегчающий дальнейшие задачи. Нам необходимо для каждого ящика получить список доступа, исключая доступ администраторов, серверов и самого титульного пользователя. Конечный сценарий может выглядеть примерно следующим образом:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Get-MailboxPermission | Where {($_.user -notlike «LIBERTINE\admin») -and ($_.user -notlike «LIBERTINE\Exchange View-Only Administrators») -and ($_.user -notlike «LIBERTINE\Exchange Organization Administrators») -and ($_.user -notlike «LIBERTINE\Exchange Servers») -and ($_.user -notlike «LIBERTINE\Exchange Domain Servers») -and ($_.user -notlike «LIBERTINE\Exchange Services») -and ($_.user -notlike «LIBERTINE\Exchange Public Folder Administrators») -and ($_.user -notlike «NT AUTHORITY\NETWORK SERVICE») -and ($_.user -notlike «LIBERTINE\Exchange Organization Administrators») -and ($_.user -notlike «LIBERTINE\Domain Admins») -and ($_.user -notlike «LIBERTINE\Enterprise Admins») -and ($_.user -notlike «LIBERTINE\SECLMAIL$») -and ($_.user -notlike «LIBERTINE\FRSTCLMAIL$») -and ($_.user -notlike «NT AUTHORITY\SELF») -and ($_.user -notlike «LIBERTINE\superoot»)} | Format-List Identity, user

Замечательно, факт наличия доступа мы определили. Но пользуются ли им? Для этого введем дополнительное условие отбора: определим ящики, в которые не смотрели последние 70 дней (но смотрели когда-либо вообще).
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Get-MailboxStatistics | Where {($_.LastLogonTime -lt (get-date).adddays (-70)) -and ($_.LastLogonTime -gt (get-date).adddays (-900))}| Get-MailboxPermission | ...

Впринципе, для завершения расследования происходящего, осталось лишь определить ящики, с которых стоит пересылка корреспонденции. Разумеется, с выводом ящика и адрес для пересылки.
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Where {$_.ForwardingAddress -ne $null} | Format-List DisplayName,ForwardingAddress

Комбинируя вышеперечисленные команды, можно, например, легко вывести прямых кандидатов на превращение старого почтового ящика в дополнительный smtp адрес для ящика ныне работающего сотрудника. Кстати, в этом примере рекомендую обратить внимание на двойное использование команды get-mailbox:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Where {$_.ForwardingAddress -ne $null} | Get-MailboxStatistics | Where {($_.LastLogonTime -lt (get-date).adddays (-70)) -and ($_.LastLogonTime -gt (get-date).adddays (-900))} | get-mailbox | Format-List DisplayName,ForwardingAddress

Да, и еще: старые ящики, даже если ими периодически пользуются, рекомендуется перенести в отдельную почтовую базу, т.к. это даст определенный выигрыш в скорости доступа для активных пользователей. После создания самой новой базы почтовых ящиков, остальное сделать несложно:
get-mailbox -organizationalUnit «libertine.su/Disabled Users» | Move-Mailbox -TargetDatabase «OldMailboxesDB»

Главное, при переносе помнить о том, что в Exchange 2007 процесс совершается от имени администратора путем последовательного копирования всех сообщений. То есть, время последнего доступа к ящику будет установлено в текущее.

• Выбирается доменный пользователь, максимально схожий по должности с принимаемым на работу
• Путем копирования создается новый доменный пользователь
• Для нового пользователя заводится почтовый ящик и т.д.

Какие типовые сценарии обычно выполняются при увольнения сотрудника:

1. Для учетной записи пользователя меняется пароль.
2. • к почтовому ящику увольняющегося пользователя дается доступ сотруднику, принимающему дела
   • вся деловая переписка архивируется и архив затем подключается к почтовому клиенту сотрудника, принимающего дела увольняющегося коллеги
3. • с почтового ящика увольняющегося пользователя ставится пересылка всей входящей корреспонденции на адрес коллеги, принимающего дела
   • почтовый smtp адрес переназначается с ящика увольняющегося сотрудника на ящик сотрудника, принимающего дела

Причем, надо отметить, если при приеме на работу, в целом, сценарии всегда одинаковы. То при увольнении могут отличаться совершенно разительно. Это может быть обусловлено необходимость дать доступ к архиву почты нескольким пользователям, что порождает действия, противоречащие обычному регламенту. А может быть обусловлено и простым отсутствием самих четких регламентов.

Таким образом, при солидном размере организации и ненулевой текучести кадров, с течением времени в Active Directory накапливается масса записей о пользователях, которые уже давно не работают в организации. Но, поскольку к учетным записям могут быть привязаны почтовые ящики, нет уверенности в том, можно ли их хотя бы сделать неактивными, не говоря уже об удалении.

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

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

Например, для того, чтобы понять, кто из пользователей, находящихся в OU marketing не входил в сеть в течении 6 недель, необходимо выполнить следующий запрос:
'dsquery user «ou=marketing,dc=libertine,dc=su» -inactive 6 -limit 0'

Можно, конечно, точно также сделать запрос о просроченных паролях на вход.
'dsquery computer «ou=marketing,dc=libertine,dc=su» -stalepwd 61 -limit 0'
Но это даст очень много ложных срабатываний, если в домене нет ограничения на срок действия пароля пользователя. Или же персонально для какой-либо учетной записи задано свойство «password newer expires». Поэтому предыдущий способ все же надежнее.

Ок, предположим, мы получили список записей о пользователях домена, которые давным давно не выполняли вход. Но что нам это дает?

• Если к ящику пользователя для кого-либо назначен доступ, удалять данную учетную запись нельзя
• Если к ящику пользователя кому-либо дан доступ, но это уже давно не актуально, запись пользователя можно удалить
• Если в организации используется какая-либо система, хранящая некие данные, основанные на доменных записях пользователей (например, CRM), удалять учетную запись пользователя крайне нежелательно.

Ладно, предлагаю решать проблемы по порядку.
Для начала предлагаю перенести все записи неактивных пользователей в отдельный OU. Для этого создадим новый OU old users в корне домена и этого напишем командный сценарий:
@echo off
for /F «delims=» %%a in ('dsquery user «ou=marketing,dc=libertine,dc=su» -inactive 6 -limit 0') dsmove %%a -newparent «ou=old users,dc=libertine,dc=su»
pause

Теперь если для данного OU мы не разрешим получать список (листинг содержимого) данного OU никому, кроме контроллеров домена, почтовых серверов и учетных записей администраторов предприятия, то получим ровно ожидаемый эффект.
Таким образом, обычный пользователь домена при запросе к LDAP серверу (например, в диалоге назначения прав на некий объект) не получит в общем списке пользователей домена указанные записи уволенных пользователей.
Одновременно, нет никаких проблем для пересылки входящей корреспонденции или работы с ранее подключенными почтовыми ящиками уволенных пользователей (т.к. права на чтение содержимого вышеуказанного OU есть у всех).

А продолжение я напишу в следующем посте

Средствами графического интерфейса управления данную задачу решить можно, разве что только, создав отдельную базу данных почтовых ящиков и указав для нее альтернативную базу общих папок. Учитывая, что в подавляющем большинстве случаев создание второй базы общих папок сопряжено с последующими проблемами (если вообще возможно), данное кривое решение абсолютно неприемлимо.

Тем более, что существует вполне штатное рабочее решение для ограничения доступа. Всего лишь необходимо использовать PowerShell (Exchange Management Shell)
При помощи командлета set-CASMailbox возможно вполне гибко управлять правами удаленного доступа к конкретному почтовому ящику.
В нашем случае интересен параметр OWAPublicfoldersEnabled и установка его в значение false. Что мы и сделаем:
set-CASMailbox -Identity userone@libertine.su -OWAPublicfoldersEnabled:$false
Отлично, мы только что ограничили доступ по всем подряд параметрам Дело в том, что изначально большинство параметров имеют неустановленные значения и, соответственно, установка одного из них приводит к несколько не ожидаемым результатам.

Соответственно, для того, чтобы установить ограничения только на нежелательные к использованию функции, необходимо принудительно выставить значения всех параметров.
Например, следующим образом:
set-CASMailbox -Identity userone@libertine.su -OWACalendarEnabled:$true -OWAContactsEnabled:$true -OWATasksEnabled:$true -OWAJournalEnabled:$true -OWANotesEnabled:$true -OWARemindersAndNotificationsEnabled:$true -OWAPremiumClientEnabled:$true -OWASpellCheckerEnabled:$true -OWASearchfoldersEnabled:$true -OWASignaturesEnabled:$true -OWAThemeSelectionEnabled:$true -OWAJunkEmailEnabled:$true -OWAWSSAccessOnPublicComputersEnabled:$false -OWAWSSAccessOnPrivateComputersEnabled:$false -OWAUNCAccessOnPublicComputersEnabled:$false -OWAUNCAccessOnPrivateComputersEnabled:$false -OWAActiveSyncIntegrationEnabled:$false -OWAAllAddressListsEnabled:$true -OWAChangePasswordEnabled:$true -OWARulesEnabled:$true -OWAPublicfoldersEnabled:$false -OWASMimeEnabled:$true -OWARecoverDeletedItemsEnabled:$true

А самым интересным является миграция с ISA 2006 на новый продукт. Я понимаю, зачем было сделано выделение роли управления массивом серверов для Enterprise конфигурации. Но что же делать тем, у кого ISA используется в, скажем так, некомплексной конфигурации?

Вот реальный пример того, как бывает:

• Когда-то давно была развернута ISA Enterprise на массив из двух серверов.
• С течением времени, некоторый функционал был перенесен на аппаратные платформы, некоторый на платформы под управлением альтернативных програмных систем.
• На момент появления желания мигрировать на новую версию продукта, фактической необходимости в Enterprise версии уже нет. Зато есть его легальная копия (точнее, разумеется, она появится сразу после выхода RTM версии продукта) и существующая конфигурация ISA 2006 Enterprise, несущая на себе около 50 публикаций различных серверов.
• Cуществующий сервер, с запасом справляющийся с нагрузкой, находится на виртуальной машине внутри кластера и, посему, к отказу аппаратного обеспечения вполне устойчив.

Вполне естественно, что поднимать полноценную Enterprise структуру в данной ситуации нерационально. Но и настраивать все полностью с нуля, откровенно говоря, не является разумной идеей.

Что ж, помочь с решением проблемы не столь и сложно. Всего то и необходимо, что обойти защиту от загрузки несовместимой конфигурации при импорте Firewall Policy.
Итак, для начала выгружаем конфигурацию с ISA сервера, включив в экспорт все данные. Копируем файл экспорта на новый TMG сервер.
Открываем файл экспорта в блокноте и ищем следующие строки по всему тексту:

• <fpc4:Build dt:dt="string">
  Полная строка будет выглядеть примерно следующим образом: <fpc4:Build dt:dt="string">5.0.5723.511</fpc4:Build>
  Заменяем всю строку на следующую: <fpc4:Build dt:dt="string">7.0.7733.100</fpc4:Build>
• <fpc4:IsaXmlVersion dt:dt="string">
  Полная строка будет выглядеть примерно следующим образом: <fpc4:IsaXmlVersion dt:dt="string">5.30</fpc4:IsaXmlVersion>
  Заменяем всю строку на следующую: <fpc4:IsaXmlVersion dt:dt="string">7.3</fpc4:IsaXmlVersion>
• <fpc4:SSLRequireSecureChannel dt:dt="int">2</fpc4:SSLRequireSecureChannel>
  Данный параметр более не поддерживается и строку необходимо удалить.
• <fpc4:Scope dt:dt="int">1</fpc4:Scope>
  Данную строку необходимо удалить.

После данной обработки, с большой долей вероятности, файл экспорта удастся успешно использовать в качестве файла импорта настроек Firewall Policy.
Останется лишь только проверить и отредактировать все настройки сетей и интерфейсов, импортировать на сервер все необходимые сертификаты и прописать их в свойствах коннекторов.

Threat Management Gateway 2010 к боям готов

Как показывает мой опыт, рядовые сотрудники редко понимают,что идя на сотрудничество с гостями, они вовсе не обеспечивают себе защиту доброжелательно следователя, который так мягко просит ему просто помочь.
Увы, все оказывается ровно наоборот — готовые сотрудничать лишь обеспечивают уникальную доказательную базу против самих себя, как соучастников каждого действия, доказательства которому будут впоследствии найдены внутри зашифрованного хранилища данных. Сложно отрицать свою осведомленность о существовании и содержании документа, если тот был найден внутри криптоконтейнера, ключ от которого был только у тебя, а о последнем факте, в предыдущем протоколе даже есть собственноручно подписанные показания.

Тот же, кто громко всех доказывает невозможность подобных действий со стороны здравомыслящих взрослых людей, очень плохо себе представляет, как себя ощущает и во что готов поверить человек, которому в прокуренном кабинете спокойным голосом рассказывают, что в обмен на сотрудничество прямо сейчас отпустят домой, а не повезут в СИЗО. И что вовсе ведь не обязательно красивой молодой девушке из-за своего глупого упорства ломать всю оставшуюся жизнь и карьеру криминальным пятном в биографии — ведь информацию все равно ищут не против нее, а всего лишь против ее работодателя.

Скажите, вам никогда не показывали, как ломается табуретка о спину? Даже если эта табуретка ломается не о вашу спину (сотрудники силовых ведомств, как известно, всегда действуют жестко в рамках соблюдения закона и прав человека), я полагаю, что зрелище способно подтолкнуть к тому, чтобы вспомнить не только все забытые пароли, но даже то, о чем ранее не подозревали.
Когда системный администратор небольшой компании с пеной у рта доказывает, что разработанная им система защиты абсолютно надежна, что каскад из двух надежных криптоалгоритмов можно вскрыть лишь полным перебором символов ключевой фразы... Он прав. Но в цепи всегда остается слабое звено, которому можно показать ту сломанную табуретку.

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

При пожарном методе внедрения, как правило принимается решения о прозрачном шифровании всего содержимого дисков рабочих станций. Это верное решение, так как вне зависимости от места хранения конфиденциальной информации, всегда есть шанс найти много интересного, проведя восстановления удаленных временных файлов. Да и не столь велики шансы того, что все пользователи всегда добросовестно используют предоставленное им средство для надежного уничтожения конфиденциальной информации, а не ограничиваются помещением файлов в корзину
Только необходимо понимать, что при этом диск будет зашифрован посекторно, то есть, со всей информацией, которая с точки зрения файловой системы уже давно является свободным пространством.

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

Не все знают, что кроме массы дорогостоящих средств для надежного уничтожения информации, существует бесплатное решение, которое можно скачать с сайта, принадлежащего компании Microsoft. Речь идет о разработанной компанией Sysinternals утилите командной строки под названием sdelete.
Итак, что нам необходимо уничтожить:

• Все временные файлы, созданные при посещении ВЕБ страниц и открытии файлов непосредственно из сообщений в стандартной корпоративной почтовой программе
• Все временные файлы, создаваемые теми или иными приложениями в процессе своей работы, которые затем традиционно не удаляются из-за природной лени авторов этих программ
• Системные временные файлы, среди которых редко можно встретить что-то ценное, но зачем хранить мусор?
• Содержимое корзины. Лично я против отключения перемещения файлов в корзину и включения немедленного удаления — рука может дрогнуть у кого угодно. Но периодически содержимое корзины имеет смысл очищать принудительно.
• Содержимое кэша установки пакетов SCCM.
• Пространство, отмеченное как незанятое на основных жестких дисках рабочей станции

Замечательно, скачаем саму утилиту sdelete и напишем командный сценарий, производящий все необходимые действия. После чего создадим на его основе пакет установки, запускающийся в разумное время и с разумной периодичностью. Очистка незанятого пространства процедура достаточно долгая, а процедура очистки корзины процедура несколько неоднозначная, поэтому необходимо тщательно продумать время и периодичность запуска.

Сам файл tempshread.cmd может выглядеть примерно следующим образом:

@echo off
for /D %%f in («C:\Documents and Settings\*») do for /D %%z in («%%f\Local Settings\Temporary Internet Files») do sdelete -p 2 -q -s %%z
for /D %%f in («C:\Users\*») do for /D %%z in («%%f\AppData\Local\Temp») do sdelete -p 2 -q -s %%z
for /D %%f in («C:\Users\*») do for /D %%z in («%%f\AppData\Local\Microsoft\Windows\Temporary Internet Files») do sdelete -p 2 -q -s %%z
for /D %%f in («C:\Documents and Settings\*») do for /D %%z in («%%f\Local Settings\Temp») do sdelete -p 2 -q -s %%z
for /D %%f in («C:\RECYCLER») do sdelete -p 3 -q -s %%f
for /D %%f in («d:\RECYCLER») do sdelete -p 3 -q -s %%f
for /D %%f in («e:\RECYCLER») do sdelete -p 3 -q -s %%f
for /D %%f in («f:\RECYCLER») do sdelete -p 3 -q -s %%f
for /D %%f in («g:\RECYCLER») do sdelete -p 3 -q -s %%f
for /D %%f in («%systemroot%\temp») do sdelete -p 1 -q -s %%f
sdelete -p 1 -z c:
sdelete -p 1 -z d:
sdelete -p 1 -z e:
sdelete -p 1 -z f:
sdelete -p 1 -z g:
for /D %%f in («%systemroot%\system32\ccm\Cache») do sdelete -p 1 -q -s %%f
for /D %%f in («%systemroot%\syswow64\ccm\Cache») do sdelete -p 1 -q -s %%f

Про то, что часть строк не является циклом, а является чесанием левого уха правой пяткой, можно в комментариях не писать — мне просто удобнее ориентироваться в такой структуре.

Есть, правда, в предложенном решении небольшая неприятная деталь: при своем первом запуске под каждым из пользователей рабочей станции, все утилиты Sysinternals выводят окно принятие пользовательского соглашения. Можно, конечно, добавить в начало нашего сценария строчку

regedit /S sdeleteadd.reg

И создать файл sdeleteadd.reg следующего содержания:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Sysinternals\SDelete]
«EulaAccepted»=dword:00000001

Но, если задуматься, это уже некорректно с точки зрения соблюдения прав использования предоставленной производителем программы.
Я, кстати, серьезно: даже такой внешне безобидный обход защиты бесплатного программного обеспечения, формально, является уголовно наказуемым деянием. Как говорится, кому не нравится принимать условия производителя, имеет полное право самостоятельно написать подобную утилиту и распространять ее со свободной лицензией.