UPDATE! All UVM email accounts have been migrated to Microsoft Exchange, and so this guide is no longer necessary. Outlook 2013 and 2016 setup is very easy, and all functionality is available.
These instructions describe a configuration for connecting to our old email system via IMAP. For connecting Outlook to UVM’s current mail service, see http://www.uvm.edu/techteam/outlook-2016-for-exchange/.
Changes in Outlook 2013
The most significant change in the new version of Outlook is the support of touch-based interfaces. In Outlook 2010, using your finger to scroll a message resulted in selecting a swath of text, as though clicking and dragging with a mouse. Outlook 2013 addresses this, and adds specific support for touch interaction with adjusted menu spacing and a thumb-based button bar that works really well on Windows tablets.
Outlook 2013 – special features available on touch devices include touch scrolling, and a button bar for the right thumb.
You’ll also notice a much cleaner design, where the faux 3D buttons and look have been simplified and flattened. I find myself selecting the dark gray
color scheme to restore some visual variety and separation, though.
One change that’s a little irritating is that you can no longer specify the folder into which copies of your sent messages are received; they go into a folder called Sent Items
. Instead, I’ve configured Pine, Webmail, and Thunderbird to use Sent Items
I continue to find Outlook a user-friendly, feature-rich email client, and I’m glad to share these instructions with you. Let’s get started. Continue reading
On Server 2008 and 2008 R2, if your Domain Controllers aren’t configured to require LDAP signing and disallow simple LDAP binds in plaintext, Active Directory Domain Services logs a warning event on startup, and summary events every 24 hours.
A couple weeks ago, I followed the recommendation to enable logging of unsigned and plaintext LDAP authentication requests. Setting the LDAP Interface Events value to 2 generates a Directory Services event 2889 for each connection.
Now I want to do some analysis of the collected events. The event structure puts the important details, namely the client name and IP address, in the big description text field. It looks like this:
Log Name: Directory Service
Date: 11/3/2010 11:46:38 AM
Event ID: 2889
Task Category: LDAP Interface
User: ANONYMOUS LOGON
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a cleartext (non-SSL/TLS-encrypted) LDAP connection.
Client IP address:
Identity the client attempted to authenticate as:
Previously, I’ve exported the logs to CSV format, then used Excel and some text-mangling functions to pull out the important details. But I noted that the two important values were nicely separated in the XML representation of the event:
Goal for today: get auto_provisioning script working.
Feeling cold; AC is blowing strong and winning the HVAC smackdown.
Made lots of progress on provisioning scripts, then hit brick wall: Need IO::Socket::SSL and Net::SSLeay in order to do Net::LDAP->starttls, and the perldap package from UWinnipeg for Perl 5.10 doesn’t have these available.
Do I try to compile myself and build PPMs? Ugh.
Maybe ActivePerl 5.8 x64 would get the job done