Skip to main content

Message Encryption for Office 365

Much anticipated Message Encryption for Office 365 is now generally available and is being rolled out, read the following article for more information.   

Message Encryption is replacing what was previously known as Exchange Hosted Encryption (EHE), and while the basic idea of using mail-flow rules for transparently enforcing encryption policies remains the same, there's one major change on the back-end. Specifically, there has been a move away from the Voltage Identity Based Encryption (IBE) to Microsoft's own Rights Management Services (RMS).

Why was this feature much anticipated? Because it enhances overall security and privacy controls within Office 365's Exchange Online component; it also does so in a customer friendly fashion by incorporating this useful functionality into higher-level O365 subscriptions (starting with E3/G3) at no additional charge (add-on for the lower-level subscriptions):   
“Office 365 Message Encryption is an easy-to-use service that lets email users send encrypted messages to people inside or outside their organization. Designated recipients can easily view their encrypted messages and return encrypted replies. Regardless of the destination email service - whether it’s Outlook.com, Yahoo, Gmail, or another service - email users can send confidential business communications with an added level of protection against unauthorized access.”
For more information, check out the following:
  • Blog post on the Message Encryption announcement - here
  • TechNet article that covers Message Encryption details - here
Also, since Rights Management Services (RMS) are essential to the Message Encryption functionality and are also a necessary component of the Information Rights Management (IRM) within different Office 365 components (e.g. SharePoint Online, Exchange Online, MS Office), it would be advisable to gain some familiarity with RMS/IRM. Here are a few helpful links:

Comments

Popular posts from this blog

Skype for Business and VTC Interoperability

Skype for Business (SfB) has a very, very strong potential, I have written about it in my previous post. I can't think of any other platform that shows as much promise in terms of bridging personal and business communications as well as unifying different modes and mediums. And all of this may have started with a strategic acquisition of Skype by Microsoft in 2011.

That said, the road ahead is not without challenges. For example, interoperability with other platforms. Making SfB work with existing Video TeleConferencing (VTC) systems, many of which represent significant capital investments in organizations' infrastructure, could be of a particular importance.

After reading statements like Skype for Business is based on Session Initiation Protocol (SIP) standards and supports H.264 (MPEG-4 video coding standard) one can come to a quick conclusion that integration and/or interoperability with other VTC solutions is easy or nearly automatic. Unfortunately, the industry is not qui…

PoSh Disable and Move AD Users

A quick and easy way to disable user accounts and move them into designated OU:

Import-Csv "C:\TEMP\users.csv" | ForEach-Object { `      $u=$_."sAMAccountName"; $l="Disabling and moving: " +$u; write-output $l; `      Get-ADUser -Identity $u | `      Disable-ADAccount -PassThru | `      Move-ADObject -TargetPath "OU=Disabled Users,OU=Organization,DC=domain,DC=local"
Input is provided via a CSV file:
users.csv (username) sAMAccountName  jdoe1  jdoe2  jdoe3  jdoe4  jdoe5  

To generate input file run something like this, review and edit as necessary:
Search-ADAccount –UsersOnly –AccountInactive –TimeSpan 180.00:00:00 | `      where {$_.enabled} | `      Get-ADUser | `      select sAMAccountName | `      Export-Csv -Path "C:\TEMP\users.csv"

WordPress displays weird characters

Sometimes after a database conversion (e.g. from MySQL to MariaDB) or due to encoding issues a situation might arise when WordPress is showing weird characters. A quick way of remedying the situation would involve examining the pages to discover a pattern (what characters are being substituted, in the example below the apostrophe was replaced by â€™) then running an queries against the database to reverse the effect. Here's a quick example (common tables that store content):



UPDATE wp_posts SET post_content = REPLACE(post_content, 'Â', '')     UPDATE wp_posts SET post_content = REPLACE(post_content, '’', "'")     UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'Â', '')     UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, '’', "'")     
Please, keep in mind that to permanently resolve the issue you would need to get to the root of the problem and may need to adjust encoding, run a databas…