Exchange 2016 - Limits and impact of Transport Rules (Mailflow Rules)

Sometimes, to solve complex problems, you have to use transport rules. But what are the limitations of this functionality?
I decided to cover 2 questions:

Part 1. How big may the transport rule be?

All transport rules are stored in the "CN=TransportVersioned,CN=Rules,CN=Transport Settings,CN=<Organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain>" container. The rule itself is a XML that is stored in the "msExchTransportRuleXml" attribute.

Exchange: How to reliably determine that a user is logged into mailbox?

Sometimes (for example while migration users are from another email system) there is a need for reliable determination that a user is logged into the mailbox (using Outlook or OWA).

The simplest answer is mailbox's lastlogontime (Get-MailboxStatistics). But it turnes out to be not quite true.
Attention! The attribute "LastLogonTime" of user's mailbox filled and updated when another user opens user's calendar.

Finally, I found 4 criterias which help to reliably determine that a user is logged into the mailbox.

1. "lastlogontime" (Get-MailboxStatistics) - necessary but not sufficient attribute.
2. "Languages" (Get-Mailbox) - this attribute filled when user entered into OWA and sometimes filled when entered into Outlook.
3. "WorkingHoursTimeZone" (Get-MailboxCalendarConfiguration) - this attribute filled when user entered into OWA and sometimes filled when entered into Outlook. Deffault value - "Pacific Standard Time", so you can use it only if users are in a different time zone.
4. "Quick Step Settings" (Get-MailboxFolderStatistics) - this is not an attribute, it is a checking for the presence of a folder "Quick Step Settings" in the mailbox, because it appears only when you open/configure Outlook.

Exchange 2016: Issue of breaking email address in angle brackets

Recently noticed the unusual behavior (an issue) of Microsoft Exchange 2016 when displaying email addresses.
If in the body of an email (Content/Header section) specify an email address (From, To or Cc headers) twice, where the second time is in angle brackets, the address will be broken. The part of the address after the first character @ moves to the address in brackets, thereby preventing the possibility of an answer to this email.

I assume that the function that should extract the correct email addresses from the headers does not work correctly.

Several tests

Original email address (that used while sending)	The final email address (OWA, Outlook)
administrator@test.local <administrator@test.local>	"administrator@" <test.local administrator@test.local>
administrator@_ <administrator@test.local>	administrator@ <_ administrator@test.local>
administrator@domain<administrator@test.local>	administrator@ <domainadministrator@test.local>
administrator@><administrator@test.local>	<administrator@>
<administrator@><administrator@test.local>	<administrator@>
<@administrator@><administrator@test.local>	<@administrator@><administrator@test.local>
administrator@<administrator@test.local>	<administrator@>
<script>@><administrator@test.local>	<script>
administrator@test.local@ <administrator@test.local>	"administrator@" <test.local@administrator@test.local>

Windows 10: DNS Client load CPU in case of big hosts file

After installing Fall Creators Update (KB4058043, KB4057247, KB4055237, KB4055994) on Windows 10 Pro 1709 (16299.125) I noticed a long delay in the opening of websites.

Symptoms

• The DNS Client service load is about 25% CPU.
• You can't open any website and get access to the internet at all for several minutes.

Microsoft Office: How to fix double slash autocorrection in links

Some applications (web servers, etc.) support hyperlinks with double-slash (//) after specifying the protocol (http://, ftp://, etc.).
IBM Lotus Domino is such an application. A link "notes://server/1111111111//2222222222/" is correct.

During the migration from the IBM Lotus Domino mail system to Microsoft Exchange, it turned out that all Microsoft Office applications (Outlook in particular) correct links (even in incoming emails) with two empty slashes "//" for a single slash "/" automatically. We failed to find a solution in the Internet to change this behavior.