Windows Store и ошибка 0x80070005

Захотелось сегодня с маркета попробовать установить пару приложений. Но столкнулся с этой ошибкой. Гугл выдавал разные варианты решения. Но ни один из вариантов мне не помогал. Потом методом тыка заметил, что не устанавливается, если выбран отличный от системного диска (То есть если ставил не в С диск). Потратив еще минут 10 нашел причину. Проблема была в галочке "Сжимать содержимое диска". После снятия галочки и удаления директорий, который Windows Store создал при установке этих приложений, все пошло. 

Отображение доменов посещенных https ресурсов в логе Squid

Есть замечательные инструкции по поднятию прозрачного прокси Squid с фильтрацией https ресурсов. В частности https://habrahabr.ru/post/272733/. Все бы хорошо (сам использую, все прекрасно работает), но кое-что меня сильно раздражало. В логах сквида вместо адреса посещенного https ресурса указывался ip адрес. В век, когда каждый второй сайт переходит на https это становится проблемой, так как не понятно, что за ресурс посещает юзер и нужно ли блокировать этот ресурс. Потратив полдня на чтение мануалов нашел правильное решение для исправления ситуации. Суть в том, что мы создаем 2 ACL и 2 logformat параметра. Отдельно для логирования запросов на 80 порт и 443. logformat для 80 порта не будет заносить в лог записи о https соединениях. А второй logformat наоборот, пишет в лог только о запросах на 443 порт. Зачем это? дело в том, что для отображения SNI записи в логе надо добавить параметр %ssl::>sni. Но тут появляется другая проблема. Для https ресурсов в логе появляется и имя домена и его IP адрес. За занесение в лог ip адреса отвечает %ru. Вот его то мы и уберем в logformat для запросов на 443 порт. В итоге у нас получаются строки:

 acl https_port port 443  
 logformat https %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ssl::>sni %[un %Sh/%<a %mt  
 cache_access_log /var/log/squid3/access.log https https_port  
 acl http_port port 80  
 logformat http %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %[un %Sh/%<a %mt.  
 cache_access_log /var/log/squid3/access.log http http_port  

Теперь в логе порядок и можно любимым парсером строить отчеты и не бояться встретить там IP адрес вместо домена (за исключением случаев когда пользователь заходит именно по IP, а не по доменному имени)

Dr.Web Esuite Server + Active Directory + Bind

Решил попробовать Dr.Web Esuite Server у себя в домене. Имею тестовый домен AD. В качестве DNS сервера используется bind9. При развертывании Dr.Web server  сразу столкнулся с проблемой при предложении установщика зарегистрировать сервис в AD. Постоянно ругался на ошибку  админа домена (мол не неправильно я его указал). Хотя логин и пароль были правильными. После 2-3 часов поиска проблем (гугл на это ничего не ответил) взял в руки tcpdump/wireshark и стал смотреть что происходит при попытке продолжить установку. И сразу увидел, что установщик пытается послать данные на порт 135 моего bind сервера. Но bind не открывает 135 порт. Его открывает процесс svhost на контроллере домена. Дело в том, что установщик смотрит, какие DNS серверы указаны в настройках подключения, так как считает, что DNS сервер находиться  на контроллере домена. И в стандартной ситуации так и бывает. Но я по некоторым причинам отказался от DNS сервера Microsoft и использовал Bind. Видимо разработчики Dr.web не учитывали такой поворот. Но вернемся к проблеме. Не долго думая я перенаправил просто все запросы на 135 порт на сервер AD с помощью правил iptables

  iptables -t nat -I PREROUTING -p tcp -d <dnsservip> --dport 135 -j DNAT --to-destination <adserverip>:135  
  iptables -t nat -A POSTROUTING -p tcp --dst <adserverip> --dport 135 -j SNAT --to-source <dnsservip>  

Где
<dnsservip> IP адрес нашего сервера DNS
<adserverip> IP адрес контроллера домена.

Сразу после добавления правил установка пошла дальше.