Ранее писал про простую, но довольно эффективную «защиту от брутфорсеров», но что делать если у вас нет роутера, на котором можно такую защиту построить?
Можно сделать «наколеночное» примитивное, но все таки работающее решение внутри самого сервера. Единственное ограничение — ОС на сервере должна быть минимум Windows Server 2012 R2.
Continue ReadingДля начала: речь идет о подписке Office365 Business Premium, той самой, где можно почту своего домена размещать на Exchange Online от Microsoft. И именно с этим связаны несколько тонкостей, которые могут пригодиться при настройке всего вот этого вот.
Решение: Есть такой способ! Читаем здесь
В моем случае решение было таким:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted $UserCredential = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection Import-PSSession $Session
первой строкой задаем политику выполнения
второй — задаем переменную которую потом используем для аутентификации (появится окошко, где надо будет ввести логин-пароль учетки администратора от служб Office365 в формате admin@my-domain.ru)
третья строка — задаем параметры сессии и четвертая строка — собственно подключаемся.
В моем случае, решение было таким: Сначала подключаемся к Exchange Online, затем выполняем две команды
Set-RemoteDomain -Identity default -TNEFEnabled $false Set-RemoteDomain -Identity My-domain-name.ru -TNEFEnabled $true
первая команда — «выключает» параметр TNEFEnable для всех исходящих писем из нашего домена (что и требовалось!)
вторая команда — «включает» параметр TNEFEnable для писем внутри нашего домена (чтоб работал функционал календарей и т.п., для которых этот формат в общем то и нужен)
В моем случае несмотря на уверения Microsoft о по умолчанию включенном лимите в 150 Мб, лимит был все таки 35 Мб, чтоб увеличить его, пришлось сделать шаги приведенные в первой ссылке (обошлось без Powershell). Учтите, только, что изменения применяются не мгновенно, в моем случае пришлось ждать пару часов.
В powershell операторы сравнения отличаются от принятой номенклатуры используемой в других языках.
Все популярные операторы сведены к нескольким таблицам
by Gistek
Чтобы не лазить каждый раз в хелп и не вспоминать, ниже перечислены наиболее часто используемые методики работы со строками в PowerShell. Просто и действенно!
by Gistek
# Возвращает отсчитываемый от нуля индекс первого вхождения
PS> "abcdeabcde".indexOf("cde")
2
# Возвращает позицию индекса с отсчетом от последнего вхождения указанного символа
PS> "abcdeabcde".lastIndexOf("c")
7
# Возвращает подстроку начиная с 1 позиции
PS> "abcdefgh".Substring(1)
bcdefgh
# Возвращает подстроку начиная с 1 позиции и длиной в 4 символа
PS> "abcdefgh".Substring(1,4)
bcde
# Вставка подстроки с позиции 0
PS> "abcdefgh".insert(0,"X")
Xabcdeabcde
# Удаление с позиции 0 длиной 2
PS> "abcdefgh".remove(0,2)
cdeabcde
# Свойство объекта - длина строки
PS> "abcdefgh".length
8
# Возвращает True, если строка содержит подстроку "cde"
PS> "abcdefgh" .Contains("cde")
True
# Возвращает True, если строка начинается с подстроки "abc"
PS> "abcdefgh".startsWith("abc")
True
# Возвращает True, если строка заканчивается подстрокой "fgh"
PS> "abcdefgh".endsWith("fgh")
True
# Возвращает True, если строка содержит подстроку "cde"
PS> $"abcdefgh" -like "*cde*"
True
# Возвращает массив , где "d" - разделитель
PS> "abcdefgh" -split "d"
abc
efgh
# Возвращает строку , объединенную из двух ":" - разделитель
PS> "abcdefgh", "xyz"-join ";"
abcdefgh;xyz
# Возвращает строку где "abc" будут заменены на "XYZ"
PS> "abcdefgh".replace("abc","XYZ")
XYZdefgh
# Возвращает строку где символы приводятся к ВЕРХНЕМУ регистру
PS> "abcdefgh".ToUpper()
ABCDEFGH
# Возвращает строку где символы приводятся к нижнему регистру
PS> "ABCDEFGH".ToLower()
abcdefgh
Столкнулся с такой проблемой — на терминальных серверах профили пользователей имеют огромные размеры, при том, что рабочие столы, папки документов — перенаправлены в сеть и не участвуют в этом безумии.
Стали разбираться и накопали несколько причин, о чем и хочется рассказать ниже.
Миграция службы DHCP с старого 2003 сервера на новый 2012R2 в целом не вызывает сложностей. Всего то нужно:
Основная проблема, с которой придется столкнуться, это перенос резервированных IP адресов.