Да, планируем сделать запись. Ссылку на запись здесь же опубликую

Есть, Windows Azure Pack. Чем принципиально отличается, упомяну на вебинаре. Одно из принципиальных отличий — Azure Stack использует тот же API, что и Microsoft Azure.

Справедливо. Это ограничение Cloud Services и классической модели. Workaround, если он применим, выше уже предложен — использовать Public IP (PIP) для экземпляров ВМ. Тогда исходящие запросы конкретной ВМ идут через этот PIP и не требуют SNAT-таблицу.

В конце этой недели, в начале следующей планируем сделать такой дайджест.

Транслировать обещали только keynotes и general sessions. Доклады будут записывать и потом выкладывать на Channel9.

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

Я бы сказал, предложили более глобальный подход. Тем не менее, AppLocker может быть полезен в связке с CI. Пример. CI-политика доверяет приложениям, подписанным сертификатом Microsoft. Но такая подпись есть у любого приложения из Windows Store. Если мы хотим определенным пользователям запретить запуск тех или иных приложений Windows Store, можно задействовать политики AppLocker.

Не соглашусь. Software Restriction Policy и ее развитие в виде AppLocker существуют далеко не первый релиз Windows. Тут Вы правы. Но они применимы только к интерактивным процессам пользовательского режима. CI можно (и нужно) применять от фактически загрузки ядра ОС до любого исполняемого кода пользовательского режима. CI-политика применяется к устройству вне зависимости от пользователя и его полномочий на машине. Второй важный момент заключается в том, что неподписанный, но нужный организации код стало проще подписать. Это позволяет прийти к ситуации, когда неподписанного кода на машине просто нет, а если таковой появляется, он не будет запущен.

Согласен, это не абсолютное средство защиты. Но добавлю несколько соображений.

1. Существует оценка, согласно которой около 95% вредоносного кода не имеет подписи. Применение политики CI, таким образом, отсекает существенное количество подобных проблем.
2. Сертификат можно скомпрометировать. Сертификат Microsoft скомпрометировать теоретически можно, но сложнее. CI можно настроить так, чтобы любой исполняемый компонент режима ядра запускался бы только при наличии подписи WHQL от MS. Кроме того, можно потребовать, чтобы помимо подписи драйвера, поставщик драйвера обладал сертификатом Extended Verification (EV).
3. Можно настроить CI на доверие только определенным сертификатом. Разработчик может подписывать свой код чем угодно. Но запускаться будет только код, подписанный сертификатом, специально сгенерированным, например, локальным центром сертификации компании. И доступ к этому сертификату, а соответственно и к возможности подписать код, будут иметь строго определенные люди.

Стандартный механизм квот File Server Resource Manager (FSRM)

Да, это особенность TP4

И можно ссылку, где на вопрос об NTFS давно ответили

NTFS, ReFS

Дело вкуса. MPS раньше был отдельным продуктом, поэтому ему уделили больше внимания. Есть план написать вторую часть по RDS, где пройтись списком по остальным новшествам.

А можно поконкретнее? О какой файловой системе речь? Чего не хватает?

По TP4 ничего нового в этом направлении пока сказать не могу. Дальше посмотрим.

Не наступайте на больное место. :) Если бы я своими руками это рассылал, уже бы сделал харакири :)

Мда… Спасибо, Сергей, разбираемся, мои извинения.

Я пока цифр не видел. Появятся — поделюсь.

Поделитесь, если не сложно