Configuring PIN Complexity with Convenience PINs in Windows 10

Applies to Windows 10 version 1709 and above.

The Microsoft support article Can’t configure a PIN when Convenience PIN and Hello for Business policies are enabled in Windows 10 has a little problem.

Under the section named “Resolution”, it says:

PIN complexity: Manage PIN complexity in the standard way by using policies that are found in the following location

Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business\PIN Complexity

However, this is not the correct location in Windows 10 version 1709 and later. The correct location is

Computer Configuration\Administrative Templates\System\PIN Complexity

which is quite a different place.

I have reported this via the “Feedback” link on the page.


Follow me on twitter: @EssentialExch

Delete text-based Exchange log files, including those from IIS

I start with a warning – don’t ever manually remove Exchange Server database log files. Just don’t do it.

Exchange Server generates log files. Lots of log files. SOME of those aren’t useful and we just want to delete them. Others of those are important and should just be left alone! In general, Exchange Server log files break down into two different types: database log files and everything else.

It is unfortunate, but all Exchange Server log files have the same file extension: “.log”. Therefore, it isn’t possible to make decisions about log files based on the file extension. Only the directory/folder in which a file is located can be used for decision making purposes. This also applies to IIS (Internet Information Services) log files – they all end with “.log”.

On Exchange Server 2013 and Exchange Server 2016, there are three important directories:

‘C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs’
‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’
‘C:\inetpub\logs\LogFiles’

The first folder contains log files for “Client Access Services” (CAS). Even in Exchange Server 2016, the CAS log files are still maintained separately.

The second folder contains log files for “all other Exchange roles (but not CAS)”.

The third folder contains log files generated by IIS.

For all three folders, the locations shown are the default locations. Discovering non-default locations takes a lot of lines of PowerShell!

Generally speaking, Exchange Server will purge its own log file folders (the first two in the list above), after they reach a certain age (for example, 30 days) or a certain size (for example, 1.5 GiB).

However, IIS never automatically purges its log file folders. Never. Ever.

Especially in the case of IIS, log files can expand to fill all of the C: volume. In the Exchange Server case, Exchange usually reaches a “steady state” – a point at which log file removal balances out log file creation. However, when adding lots of new users or in the case of a new mobile OS version (this has been seen several times with iOS), a significant spike can be experienced in Exchange Server log files (especially the CAS log files).

This script will remove log files from the three named folders. By default, the log files must be at least 3 days old.

Other scripts may allow you to compress and store these log files. That’s great. And in certain situations, log files can provide a lot of information.

But for 99% of my clients – they just want to free up disk space – which this script allows.

The script is available here.

If you have questions or problems, send those to the author, michael at TheEssentialExchange dot com.


Follow me on twitter: @EssentialExch

Get-FrameworkVersion 1.6

In early December of 2017 I posted Get-FrameworkVersion 1.5. The cmdlet’s job was to examine a particular computer for all versions of the Windows .NET Framework installed on that computer. It has the capability of scanning the local computer or a remote computer. Remote computers can be accessed using CIM (with or without DCOM) or Windows RPC (also known as the Remote Registry Service).

This new version adds checking and reporting for BlockNetFramework registry key values. Each version of the .NET Framework can be blocked by creating a registry key value named BlockNetFramework<version> and setting the value data to a non-zero number. For example, BlockNetFramework472 with a value data of DWORD 1 would suppress the installation of .NET Framework 4.7.2. See the image below:

regedit image

Get the script on the TechNet Gallery: Display a list of all .NET Framework Versions installed on a computer.


Follow me on twitter! @EssentialExch

Exchange 2016 CU8 Issue Occurs in Hybrid Mode

Exchange 2016 CU8, when installed in hybrid mode, has a free/busy issue. This issue occurs when mailboxes are present both on-premises and in the cloud . A free/busy query from Office 365 to on-premises will fail for cloud-based mailboxes if those mailboxes do not have an archive enabled. The problem occurs because OAuth connectivity fails.

For Office 365 users who have an archive enabled, this problem does not occur. The obvious workaround is to enable an archive for the cloud-based mailboxes.

If the workaround is not acceptable, an IU (Interim Update) is available from Microsoft CSS for this problem. The problem should be corrected in Exchange 2016 CU9. The KB describing the IU is KB4058297. The IU is available at no charge if you cannot wait until the release of CU9.


Follow me on twitter: @EssentialExch

Windows Speculative Execution Client/Server Patches/Mitigations/Detection Summary

Not intended to be comprehensive, but as of the morning of 4-January, all the worthwhile information I can find published by Microsoft on the Speculative Execution issue:

Note that the “Install-Module” PowerShell cmdlet requires PowerShell v5 or above. 

Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities
https://support.microsoft.com/en-us/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe 

Windows Server Guidance to protect against the speculative execution side-channel vulnerabilities
https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution-s 

Important information regarding the Windows security updates released on January 3, 2018 and anti-virus software
https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released 

ADV180002 | Guidance to mitigate speculative execution side-channel vulnerabilities
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002 

Public disclosure
https://bugs.chromium.org/p/project-zero/issues/detail?id=1272 

SQL Server Guidance to protect against speculative execution side-channel vulnerabilities
https://support.microsoft.com/en-us/help/4073225 

Microsoft Cloud Protections Against Speculative Execution Side-Channel Vulnerabilities
https://support.microsoft.com/en-us/help/4073235

I have not found any evidence of a KB for Exchange Server Guidance.

Client Patch (Windows 10)
https://support.microsoft.com/en-us/help/4056892/windows-10-update-kb4056892

Server Patch (Server Core 1709)
https://support.microsoft.com/en-us/help/4056892 

Server Patch (Server 2016)
https://support.microsoft.com/en-us/help/4056890 

Server Patch (Server 2012R2)
https://support.microsoft.com/en-us/help/4056898 

Server Patch (Server 2008R2)
https://support.microsoft.com/en-us/help/4056897 


Follow me on twitter: @EssentialExch

Display All Forwarding Information for Mailboxes in Exchange On-Premises and Office 365

Completely coincidentally, Microsoft today published a blog post The many ways to block automatic email forwarding in Exchange Online and today I have a companion script to display all forwarding information for a selected set of mailboxes – working both on-premises and for Office 365.

Obviously, you don’t want to turn off forwarding until you know who and what will be affected!

You can find this script on the TechNet Gallery here: Display All Forwarding Information for Mailboxes in Exchange On-Premises and Office 365.


Follow me on twitter: @EssentialExch

December 2017 Quarterly Exchange Updates

Microsoft has released Exchange Server 2016 CU8 (download) and Exchange Server 2013 CU19 (download) for on-premises servers today. This is exactly three months to the day since their last release (which I discussed in this blog post: September 2017 Quarterly Exchange Updates).

The Microsoft blog post on the topic can be found here: Released: December 2017 Quarterly Exchange Updates.

Little has changed, quite frankly. But both updates include the security patches released last week.

Most notable changes:

  1. Support for .NET Framework 4.7.1 in both Exchange 2013 and Exchange 2016.  You must apply the update to the .NET Framework AFTER you install the Cumulative Update!
  2. Exchange no longer changes the TLS configuration for an Exchange Server when a CU is applied. The Exchange Team has promised that recommendations for the TLS configuration will soon be forthcoming.
  3. If you are running hybrid, there is now support for Hybrid Modern Authentication (this is discussed in detail here).

Please remember a few things:

You should always test in a lab first.

Your installation of a CU may fail or take significantly longer if you don’t disable anti-virus and anti-malware software before the installation.

If you have a large number of servers, you should probably drain and place each server in maintenance mode before applying the CU (and then return them to operational mode after!).

I generally find that things go more smoothly if you reboot your server “very first thing”.

Not every CU may contain changes to the Active Directory Schema, or to RBAC roles, or many other things. But life can often be made simpler by doing a PrepareSchema and a PrepareAllDomains before executing the upgrade. On my first server to be upgraded, my normal process is this:

setup /IAcceptExchangeServerLicenseTerms /PrepareSchema
setup /IAcceptExchangeServerLicenseTerms /PrepareAllDomains
setup /IAcceptExchangeServerLicenseTerms /m:upgrade

Use an elevated cmd.exe session, not a PowerShell session. (PowerShell searches the path differently than cmd.exe – PowerShell will find the setup.exe in $exbin instead of the setup.exe in the current folder.)

After the upgrade, you should again reboot. Then re-enable your anti-virus and anti-malware. Finally, place the server back in operational mode.

Happy upgrading!


Please follow me on twitter! @EssentialExch

Display Special Permissions for Mailboxes in Exchange On-premises and in Office 365

You need this script, even if you don’t know you need it. 🙂

If you manage a group of email users, over time you have probably granted permissions for various users over other user’s mailboxes.

This is really common. For example, an administrative assistant will often need access to open her supervisor’s mailbox. And also to send mail as if she was the supervisor.

Another example is when a support representative will need to send email as if the representative was the destination support mailbox.

These represent three common special permissions: Send-As, Send-On-Behalf, and Full-Control.

This script reports on a select set of mailboxes, and who has these special permissions on those mailboxes.

With the Filter and OrganizationalUnit (OU) parameters, the administrator executing the script can easily restrict the inspected mailboxes to a desired subset.

This is common information you need to properly audit access to mailboxes in an on-premises Exchange environment – or in Office 365. This script works with both on-premises Exchange mailboxes and Office 365 mailboxes.

When you have decided to migrate to Office 365, you need to know what permissions are assigned to which mailboxes, in order to duplicate these permissions in the cloud environment.

You can acquire the script here: Display a set of special permissions and capabilities on a group of mailboxes.

Azure Classic Portal – “He’s almost dead, Jim!”

As I noted in my post Azure Classic Portal – More Pieces Removed, the writing was on the wall for the Classic Portal.

Now, the end of the line is in sight. It was announced on December 6, 2017 that the Classic Portal will be (in Microsoft terms) sunsetted, effective January 8, 2018. That means “it’s gone”. For more information, read Azure portal update for classic portal users.

All services from the Classic Portal are now available in the modern Portal. The end is nigh! Update your processes and procedures to use the modern Portal.


Follow me on twitter! @EssentialExch

Get-FrameworkVersion 1.5

Recently I posted Get-FrameworkVersion. The cmdlet’s job was to examine a particular computer for all versions of the Windows .NET Framework installed on that computer. This was a version 1.0 effort, but it did the job, especially when you were interested only in the local computer. So, if you didn’t mind copying the script to every computer you were interested in, all was great!

However, the requests came in quickly to add support for scanning remote computers. This wasn’t surprising.

This sounds like a simple request, but how to provide it (given no control over a company’s infrastructure) is not as obvious. So, in this version, I’ve added remote support, and made a couple of SWAGs about the best ways to do it. Let me know how it works for you!

I’ve also added extensive help and examples to the cmdlet, as well as documented the internal operation of the cmdlet (for the PowerShell scripters out there).

Get the script on the TechNet Gallery: Display a list of all .NET Framework Versions installed on a computer.


Follow me on twitter! @EssentialExch