Practical Help for Exchange & Office 365
On February 29th I had the great pleasure of being a guest on the RunAs Radio podcast. I joined host Richard Campbell to discuss all the new security requirements coming to Exchange Online, specifically around the new modern authentication requirement and the deprecation of TLS 1.0 and 1.1.
(Originally posted at http://runasradio.com/shows/show/684)
I have had a few instances where customers have blocked OneDrive in their Office 365 tenant. This is often the result of a looming Exchange 2010 support deadline and a lack of time to establish governance, security, compliance, and training around both Exchange and every other service in Office 365. Unfortunately, the methods used to block some of these services may have unexpected consequences.
In each of these instances, OneDrive was blocked by removing the user’s ability to create OneDrive storage in the tenant. SharePoint Online was also in its default out-of-the-box state with default permissions. In each case we ran into the following symptoms:
In the next sections, we show how the OneDrive block was put in place and how SharePoint was configured to cause this perfect storm of incorrect attachment saving. We will then identify a workaround for the issue.
The method described in this section is commonly found on the internet to block OneDrive access for users. In all cases, OneDrive was configured using this method.
The block is configured by navigating to the SharePoint Admin Center and selecting More Features. From the More Features window, click the Open button under the User Profiles section.
From the User Profiles screen, select Manage User Permissions. On the Permissions for User Profile dialog, select Everyone except external users. In the Permissions box, Create Personal Site was unchecked. When unchecked this removes the user’s ability to create a personal OneDrive site.
Note: This method does not affect users with existing OneDrive storage. To revoke access to existing storage, the site collection admin for each OneDrive personal store would need to be replaced.
[Read more…] about Blocking OneDrive may save attachments to the default SharePoint document libraryOne of the great unsung heroes is Log Parser Studio. This utility allows you to easily parse through gigabytes upon gigabytes of IIS logs to find the information you need. Without this tool, this task is tedious in a single Exchange server environment and orders of magnitude worse in Exchange environments with many servers.
Log Parser Studio is great when it comes to migration planning and discovery, and it is a tool I always have in my tool belt. It does not matter if you are migrating to a newer version of Exchange or Office 365; Log Parser Studio can aide in the planning for both scenarios. For discovery, I use it in the following two ways:
With the third-party integrations and clients identified you can then add them to your migration plan and determine the next steps. This could include upgrading legacy Office clients, or, testing the integration of a third-party app against the target system.
Discovery with Log Parser Studio becomes especially useful in environments where Exchange predates the current IT team, or, knowledge and documentation have been lost over time.
In this article, we will explore how to use Log Parser Studio to identify the multitude of client software and third-party integrations.
Let’s get started!
Log Parser Studio comes in two downloads. The first is the original command-line utility known as Log Parser. The second is Log Parser Studio which was later developed to give a GUI to that command-line. We will need to download both components for this process.
Tip: I recommend installing Log Parser on a workstation and not directly on an Exchange server. That way we avoid adding unnecessary CPU cycles to the Exchange server.
First, we need to install Log Parser 2.2. Double-click on the LogParser.msi. On the installation screen, click Next. Accept the license agreement and click Next. On the Choose Setup Type screen click Complete. Click Install. After the install completes, click Finish.
Next, we need to install Log Parser Studio. Unzip the file LPSV2.D2.zip (I recommend unzipping this to your desktop). Open the newly created LPSV2.D2 folder and launch LPS.EXE.
This will launch Log Parser Studio.
Ran into a strange issue recently during an Exchange 2010 to 2016 migration. Internal mail sent from Exchange 2016 to Exchange 2010 was stuck in the mail queue. The queue viewer on Exchange 2016 reported the following error.
{LED=451 4.4.397 Error communicating with target host. -> 421 4.2.1 Unable to connect -> SocketTimedout: Socket error code 10060};{MSG=};{FQDN=<external.companyname.com>};{IP=<external IP>};This is a fairly generic error and I have changed the FQDN and IP address in the example above. But the key here is that the Exchange 2016 server was trying to send all internal mail to the public IP of the Exchange 2010 server versus the internal IP.
For example, if a test user on Exchange 2016 tried to send an email to a test user on Exchange 2010, 2016 was routing the mail externally out of the firewall, only to try and hairpin back to one of the public-facing IPs.
This kind of hairpin attempted by Exchange was immediately blocked by the firewall which determined that internally sourced connections should not be trying to enter the public side of the firewall.
[Read more…] about Improperly configured DNS causes internal mail to hairpin via firewall
This
As always, test these updates in a lab first! I recommend checking out this 7-part guide on configuring Exchange in your lab. It doesn’t take much to get one going.
The updates are as follows:
Exchange 2019 Cumulative Update 5 (VLSC)| KB4537677
Exchange 2016 Cumulative Update 16 | KB4537678 | UM Language Pack
In this series of cumulative updates, Microsoft has resolved a number of security and non-security issues. You can read more about those in KBs 4537677 and 4537678.
This series of cumulative updates shipped with a new version of the calculator for Exchange 2019. This new calculator corrects an issue where developing a design around mailbox size or IOPs was not producing the correct number of mailboxes per database.
Cumulative Update 5 also corrects an issue in the Manage-MetaCacheDatabase.ps1 script that ships with Exchange 2019. The script has been corrected to only return solid-state disks that are initialized. It does this by filtering out all disks with no disk number. This issue was first identified in this article.
These Cumulative Updates also fix an issue with how cookies are handled in Google Chome 80 and later. The SameSite cookie issue was first identified in this post.
[Read more…] about Exchange March 2020 UpdatesI have had a few projects now where one of the security requirements for Office 365 was to implement a conditional access policy that blocked legacy authentication (also known as basic auth). What this block does is enforce modern authentication for all clients. Any clients not using modern authentication will be denied access to all Office 365 resources.
In each of these projects, these security policies were enforced prior to moving any mailboxes to Exchange Online. In each case we ran into the same two symptoms:
In all cases, the conditional access policy was scoped to all users and all cloud apps.
Conditions scoped under Client Apps were set to include Mobile apps and desktop clients with a subitem of Other clients. No other conditions were set. The access control was to Block access.
Note: “Other clients” includes clients that use basic/legacy authentication, and do not support modern authentication. Reference: Conditional Access: Conditions
After we migrated a mailbox and Outlook failed to reconfigure (continuous legacy auth prompts) we could see the failure under Azure AD Sign-Ins. Oddly our Outlook client (Office ProPlus) which supported modern authentication was being blocked due to legacy authentication.
Adding an external sender notification to the top of an email is an important distinction for many companies. This disclaimer quickly identifies to its end users when a message is sourced from an external sender. This eliminates the guesswork for internal users, helping them to identify potential phishing attacks but also a great reminder when it comes to data loss prevention as they reply.
Companies approach this disclaimer in many different ways. Two common examples are a disclaimer prepended at the top of the email, or, adding a keyword in the message subject.
Thankfully, adding this is a simple process in Office 365 (and also Exchange on-premises – the instructions are identical).
For this article, our example company, Time Travel Research, wishes that all inbound email from external senders is prepended with a disclaimer stating the sender is external to the organization. Time Travel Research wants to ensure that every instance of an external email, even those in the same email chain, is prepended with this disclaimer.
Let’s get started!
Log in to the Exchange Admin Center. Once logged in, navigate to Mail Flow >> Rules. Click the New (
) button.
From the drop-down menu, you will notice several choices. These choices are predefined rule templates. We will create a rule from scratch. Select Create a new rule.
This
As always, test these updates in a lab first! I recommend checking out this 7-part guide on configuring Exchange in your lab. It doesn’t take much to get one going.
The updates are as follows:
Exchange 2019 Cumulative Update 4 (VLSC)| KB4522149
Exchange 2016 Cumulative Update 15 | KB4522150 | UM Language Pack
Back in September, the Exchange Team announced that is was extending support for Exchange 2010 by nine months. Exchange 2010 now shares the same end-of-life date as Office 2010 and SharePoint 2010, which is October 13th, 2020.
While this extension allows for a little more breathing room, it does not extend support for Windows Server 2008 R2, which is the underlying operating system for many Exchange 2010 installations. Server 2008 R2 will still go end of life on January 14th, 2020.
The Exchange Team has provided this extension to allow companies more time to migrate to a newer email platform, such as Office 365, or, Exchange 2016.
Unfortunately, there is no direct path to Exchange 2019 from 2010. If you do plan to stay on-prem, you will need to migrate to either 2013 or 2016 (I’d recommend 2016 as 2013 is now in extended support). From there you can migrate to 2019.
For more information on migrating from Exchange 2010 to 2016, check out this recent blog article from the Exchange Team: Exchange On-Premises Best Practices for Migrations from 2010 to 2016
In this series of cumulative updates, Microsoft has resolved a number of security and non-security issues. You can read more about those in KBs 4522149 and 4522150.
Most notably this fixes an issue I had run into myself in both Exchange 2016 CU13 and CU14. The issue was after running the Hybrid Configuration Wizard you could no longer modify the Outbound to Office 365 send connector if your source servers were Edge Transport servers.
Attempting any modifications to the send connector would result in the errors: Error 0x5 (Access is denied) from cli_GetCertificate or Error 0x6ba (The RPC server is unavailable) from cli_GetCertificate. This error was caused because the Exchange organization was attempting to access the certificates on the Edge Transport servers. I can confirm CU15 resolved this error for me.
Note: Error 0x5 (Access is denied) from cli_GetCertificate was also reported in Exchange 2019 CU2 and CU3. It has been resolved in CU4.
[Read more…] about Exchange December 2019 Updates