Category: работа

Category was added automatically. Read all entries about "работа".

я

Бизнес-идея

- Здравствуйте, Вы позвонили на контактный телефон компании "***", специально предназначенный для приема звонков от торговых агентов. Пожалуйста, не вешайте трубку, Ваш звонок очень важен для нас.

(играет легкая музыка)

- Здравствуйте, Вы позвонили на контактный телефон...
я

К прошлому письму.

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

Проблемы с часовым поясом (Timezone) в Microsoft System Center Data Protection Manager

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

Расписание всегда составляется, исходя из локального времени защищаемого сервера. То есть, если Вы видите в консоли задание, запланированное на 2 часа ночи, то это будут два часа ночи по местному времени защищаемого сервера, а вернее, это будет то время, в которое, по мнению сервера DPM, на защищаемом сервере наступит два часа ночи.

И вот тут начинаются проблемы. Допустим:

1. Вы неправильно установили часовой пояс на защищаемом сервере, или просто забыли его установить до момента добавления сервера в DPM, или
2. Вы перенесли сервер в другой часовой пояс, или
3. Описание часового пояса изменилось, в соответствии с решениями государственных органов

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

По счастью, решение есть, правда его надо использовать на свой страх и риск.

1. Сделать бэкап базы DPMDB командой DpmBackup -db
2. Подключится к экземпляру SQL сервера, использующегося сервером DPM (в моем случае MSDPM2012) с помошью SQL Management Studio.
3. Выполнить нижеследующий запрос (для часового пояса UTC+3, для других часовых поясов все будет по-другому)

use DPMDB
go

update tbl_AM_ServerTimeZone set
Bias = -180 ,
Description = '(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)' ,
DaylightName = 'Russia TZ 2 Daylight Time' ,
DaylightBias = -60 ,
DaylightYear = 0 ,
DaylightMonth = 0 ,
DaylightDayOfWeek = 0 ,
DaylightDay = 0 ,
DaylightHour = 0 ,
DaylightMinute = 0 ,
DaylightSecond = 0 ,
DaylightMillisecond = 0 ,
StandardName = 'Russia TZ 2 Standard Time' ,
StandardBias = 0 ,
StandardYear = 0 ,
StandardMonth = 0 ,
StandardDayOfWeek = 0 ,
StandardDay = 0 ,
StandardHour = 0 ,
StandardMinute = 0 ,
StandardSecond = 0 ,
StandardMillisecond = 0 

from tbl_AM_ServerTimeZone join tbl_AM_Server on tbl_AM_Server.ServerId = tbl_AM_ServerTimeZone.ServerId
where NetbiosName='%PUT SERVER NAME HERE%'

go



Источник: http://raunomagi.blogspot.ru/2013/09/resolve-dpm-agents-time-zone-problems.html
я

О некоторых загадочных ошибках при установке обновлений на Windows 7

Симптомы: Некоторые обновления Windows не устанавливаются с ошибками 0x80070643, 0x80070005 или с каким-то еще. При этом в корне системного диска остаются папки со случайными буквенно-цифровыми названиями.

Дополнительно: Ошибки происходят только с обновлениями, устанавливаемыми как .exe-файл. Обновления .msu, .cab устанавливаются нормально.

Причиной такого поведения может быть неправильный уровень Mandatory Access на корень системного диска. Дополнительную сложность добавляет то обстоятельство, что в графическом интерфейсе Windows не видны Mandatory Access Labels.

Как проверить: используйте команду icacls на корень системного диска
C:\>icacls \
\ NT AUTHORITY\система:(OI)(CI)(F)
  BUILTIN\Администраторы:(OI)(CI)(F)
  BUILTIN\Пользователи:(OI)(CI)(RX)
  Обязательная метка\Низкий обязательный уровень:(OI)(CI)(NW) <--- НЕПРАВИЛЬНО!

Успешно обработано 1 файлов; не удалось обработать 0 файлов


Как исправить:
C:\>icacls \ /setintegritylevel (OI)(NP)(IO)H
обработанный файл: \
Успешно обработано 1 файлов; не удалось обработать 0 файлов


Как должно быть:
C:\>icacls \
\ NT AUTHORITY\система:(OI)(CI)(F)
  BUILTIN\Администраторы:(OI)(CI)(F)
  BUILTIN\Пользователи:(OI)(CI)(RX)
  Обязательная метка\Высокий обязательный уровень:(OI)(NP)(IO)(NW)

Успешно обработано 1 файлов; не удалось обработать 0 файлов


И, на всякий случай, по-английски:

НЕПРАВИЛЬНО:
C:\>icacls \
\ BUILTIN\Administrators:(OI)(CI)(IO)(F)
  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
  BUILTIN\Users:(OI)(CI)(RX)
  Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)


ПРАВИЛЬНО:
C:\>icacls \
\ BUILTIN\Administrators:(OI)(CI)(IO)(F)
  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
  BUILTIN\Users:(OI)(CI)(RX)
  Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)


Источник: https://support.microsoft.com/en-us/kb/970789
я

Ура! Я ее победил!

Проблема: При первом запуске Outlook 2016 падает в момент автоопределения (autodiscover) параметров сервера Exchange (в нашем случае Exchange 2010).

Поскольку ручная настройка профиля для Exchange в этой версии выпилена, такое поведение становится проблемой.

Через два рабочих дня опытным путем удалось определить, что проблема снимается, если отключить proxy-сервер, хотя бы на время запуска Outlook. Однако это, разумеется, не решение для корпоративной среды.

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

InternetSettings.xml

я

Onedrive versus SRP

Проблема: через некоторое время после входа нового пользователя появляется стандартное сообщение SRP (Эта программа заблокирована системным администратором) относительно файла FileSyncConfig.exe.

Это сообщение появляется потому, что Майкрософт устанавливает и пытается выполнить исполняемые файлы приложения Onedrive в каталог пользователя (%APPDATA%), что входит в противоречие с любой более-менее вменяемой политикой безопасности.

На мой взгляд, это ошибка со стороны Microsoft.

Как это работает: в профиле нового пользователя есть ключ HKСU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\OneDriveSetup = C:\Windows\SysWOW64\OneDriveSetup.exe /thfirstsetup

Как он там оказался: при создании профиля путем копирования из C:\Users\Default.

Как этого избежать: Тут есть два варианта

1. при помощи DISM смонтировать установочный образ, загрузить в regedit файл C:\Users\Default\NTUSER.DAT, удалить ключ, выгрузить файл и размонтировать образ.

2. отредактировать файл SetupComplete.cmd, добавив строки

rem Remove OneDrive Setup
reg load HKEY_USERS\#Default "C:\Users\Default\NTUSER.DAT"
reg delete HKEY_USERS\#Default\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v OneDriveSetup /f
reg unload HKEY_USERS\#Default
я

Ох, ЛОЛ

http://geektimes.ru/post/251062/

...Но ошибка была о программном обеспечении спутника на базе Linux. Каждые 15 секунд спутник отправлял сигнал радиомаяка. Одновременно данные дописывались в файл beacon.csv. Неумолимо приближался момент, когда файл занял всё доступное пространство памяти в 32 мегабайта и полетное ПО упало. Оказывается производитель платы управления уже имел версию ПО с исправленной ошибкой, но спутник не был обновлен до актуальной версии.
я

Жизнь - боль

Полночи вчера пытался понять, в чем причина ошибки 0x800706f7 при вызове функции cryptcatadminaddcatalog (что приводит к невозможности установки обновлений, например), и к пяти утра даже нашел, что причина в KB3004394.

А сегодня Microsoft отозвала это обновление.