Disable POP3 and IMAP on all mailboxes Office 365

I was recently annoyed to learn that there is no tenant wide way to disable POP3 or IMAP in Exchange Online.  Luckily PowerShell makes this task quite simple.  This article discusses the various commands that are available, but essentially you'll need to connect to Exchange Online via PowerShell and then run:

Get-User -ResultSize Unlimited | Set-CasMailbox -PopEnabled $false -ImapEnabled $false

Unfortunately you'll have to remember to disable these protocols for every new mailbox that is provisioned. This can also be performed from the ECP in the Mailbox Features.

Install vSphere 4 client on Windows 10

I ran into a number of errors attempting to install an older vSphere client in Windows 10. The first error says "This product can only be installed on Windows XP SP2 and above".  This issue is described in this VMware KB article.  I fixed this by right-clicking the installer executable and selecting to run it in Windows XP SP3 compatibility mode.  After that the installer seemed to run but would ultimately silently fail without installing anything.  It turns out that the installer requires .NET 3.5 to be installed.  These instructions from Microsoft show how to install this prerequisite in Windows 10, and it did not require a reboot for me.  Once vSphere 4 was installed I was able to successfully run it as well as update to later version when connecting to vCenter servers on newer ESXi.

Spiceworks HTTPS Redirect Breaks Stuff

We recently moved our Spiceworks installation to HTTPS.  While there's a handy setting in the options to force user connections to the portal to use HTTPS, this doesn't affect the backend used by admin and helpdesk staff.  There's a lot of bad advice out there about how to accomplish this redirect. Many threads like this one suggest adding a 302 redirect to a port 80 virtualhost to redirect to https.  While this does appear to work initially you will find that incoming emails no longer generate tickets.   If you view the production.txt log in C:\Program Files(x86)\Spiceworks\log\ you'll see an entry like this:

I[08:12:09.44 9b1030] scheduled call to check for ticket email url_ping: /tickets/check_email (http://127.0.0.1:80/tickets/check_email)
W[08:12:09.44 9b1030] check for ticket email url_ping: /tickets/check_email => unexpected response: Net::HTTPMovedPermanently

Yep, that's right - Spiceworks uses an internal API on port 80.  What's worse is that it does not follow the 302 redirect correctly, so if you go this route it will not work.  Luckily there are a number of other threads like this one on the Spiceworks forum that have a better suggestion - using Apache mod_rewrite to accomplish the task.  Specifically you will need to add the following directives to the httpd.conf file in C:\Program Files(x86)\Spiceworks\httpd\conf:

RewriteEngine On
RewriteCond %{REMOTE_HOST} !^127\.0\.0\.1
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

This will also require that you have the directive:

LoadModule rewrite_module modules/mod_rewrite.so

somewhere in the config but this appears to happen by default.  Essentially this will rewrite any HTTP requests to HTTPS with the exception of 127.0.0.1, the loopback addressed used by Spiceworks for internal API calls.

Hybrid Exchange Writeback Permissions

I recently ran into an issue after configuring Azure Active Directory Connect with hybrid Exchange that certain attributes couldn't be written back to the on-prem directory.  This manifests as errors in the sync tool, specifically a "Connected data source error code 8344" and "Insufficient access rights to perform the operation" on the export task. There's plenty of documentation that shows which permissions are required to support writeback of exactly 8 attributes.   For some reason it seems that the AAD Connect setup tool does not correctly add these permissions when selecting Hybrid Exchange mode.  There's a number of scripts out there, but two that I'll point out are this one from the Technet Gallery which appears to support a number of different configuration scenarios, as well as this one from c7solutions which is quite simple but effective.  The c7 post also has a great explanation of why these types of scripts are necessary.  The script is so useful that I've also generated an archive of the page here, in case it is ever moved/removed.

After running the script for a couple of minutes most export errors were resolved.  The specific issue can also be caused by an AD object with blocked inheritance.  This script from the technet gallery can be used to discover which users have inheritance blocked.  Once found they can either be fixed, or could be manually targeted for permissions with the aforementioned scripts.

Princeton Bitcoin Textbook

In case you hadn't heard Bitcoin hit at an all-time high of over $2,400 USD / BTC today.  There's plenty of good cursory information about Bitcoin but if you're looking for a decent in depth discussion of Bitcoin, related protocols, and other associated topics check out this book published by Princeton University Press.  The book is particularly suited to readers who already have an understanding of cryptography, computer science, networking etc.  If you're interested in going even deeper there's also a Coursera course to accompany it developed by one of the authors of the book.

O365 Migration Endpoint Creation Error

When creating a migration endpoint you may receive the error that "No MRSProxy was found running at 'name.domain.com'" with the name of your email server from autodiscover.  If you check the EWS virtual directory you will see that in fact the MRSProxy is enabled.  Further, if you check the application event log on the Exchange server you will see Event ID 1309 from Source ASP.NET.  This was a very frustrating error as it prevented the creation of migration endpoints on either the Exchange on-prem or online side of the equation.  Luckily I came across this thread which explained that it's necessary to  recycle the MSExchangeServicesAppPool on the on-prem Exchange server.  This was a quick fix with no observable impact to users.  After performing this step migration endpoint creation was quick and painless.

Audit File System in Server 2012 R2 and Event 4656

When I recently enabled file system auditing on a Windows Server 2012 R2 I was overwhelmed by the volume of events generated.  I'm talking >4 GB/day in some instances!  When I manually inspected the security event logs it appears to me that the majority of the events generated were event id 4656.  According to all of the documentation I can find this event should only be logged if the Audit Handle Manipulation subcategory of Object Access auditing is enabled.  In my case I hadn't enabled it!  Even the official MS documentation doesn't mention that event.

When searching for info I came across this comment at the bottom of a serverfault post:

Currently, under Server 2012 R2 events 4656 will generate even if Handle Manipulation category is disabled. In our case, we have enabled Audit File System category which was only generating 4660-4663 events on previous Server versions (2008-2008R2-2012) but on Server 2012 R2 this initiates overwhelming flow of 4656 events. The issue has been reported to Microsoft however there is no resolution yet.

I've yet to come across any official discussion of this, but  this certainly corresponds with my experience.  This thread was from June 2016, with a followup comment in January 2017.  Is this an undocumented feature?  A bug?

Luckily for me I'm using Splunk to ingest these logs so I was simply able to add:

blacklist1=EventCode="4656"

in the [WinEventLog://Security] stanza of C:\Program Files\SplunkUniversalForwarder\etc\apps\Splunk_TA_windows\local\inputs.conf in order to filter it out.  YMMV!