Quantcast
Channel: Joe Palarchio, Author at Perficient Blogs
Viewing all 67 articles
Browse latest View live

Office 365 – Can OWA Be A Replacement For Outlook?

$
0
0

I’ve had a few clients recently that have asked about using OWA instead of Outlook as their primary mail client. It’s a valid question given that users are very familiar with web-based email and likely use a similar interface with their personal email. If OWA meets all of your users’ needs, using OWA can help to reduce the installed applications that have to be maintained and supported on each user’s workstation.

Microsoft has consistently delivered the message that the OWA interface will likely see updates and enhancements more quickly than the Outlook client. While Office 2016 helps Outlook catch up in a few areas, there are still differences between the two interfaces.

Below are some observations when trying to use OWA as replacement for Outlook.

What’s In A Name?

Just to get it out of the way, OWA has technically been renamed “Outlook on the Web” although I don’t believe there’s consensus yet on what acronym to use (OotW?, OW?) if any at all. That said, whether you call it “Outlook Web Access”, “Outlook Web App” or “Outlook on the Web”, we all know we’re talking about the web interface through which you access your Exchange Online mailbox.

Select A Browser

As you can imagine, the web browser you use plays a role in your OWA experience. You’ll want to use the most current version of Internet Explorer for the most optimal experience. Other current browsers will work with small nuances but an outdated browser will throw OWA into the pretty limited “light mode” (Internet Explorer 9 will be limited to “light mode” beginning in January 2016). Even the latest and greatest Microsoft Edge has some limitations when it comes to OWA.

Cloud First

Since OWA is essentially a component of Exchange Online, it’s logical that features are easier to roll into the cloud service than it is getting them into the Office suite. For this reason, you see things like “Office 365 Groups”, “Clutter”, and the new “Pin” and “Sweep” actions in OWA before they appear in Outlook. Users of Office ProPlus likely have a better chance of seeing some of these new features on a more routine basis than those running MSI installations of Office that get patched on a less frequent cycle.

OWA As Your Primary Mail Client

Here are some of deficiencies observed when trying to use OWA as a replacement for Outlook:
Calendar Notifications – Most people I know pretty much live off their calendar alarms. If I have a meeting where the alarm has been removed for some reason, there’s a good chance I’ll overlook it on my schedule. In Outlook, the calendar alarms are pretty front and center by default, there’s almost no missing them. In OWA, the alarms can be overlooked when you’re running multiple tabs or browser sessions. Additionally, it takes some training to get to the point where you realize that closing your browser means closing your mail client and thus your alarm notifications. Given we’re probably getting the alarm notification on our phone, tablet or watch, perhaps this isn’t that big of a deal but it’s a change in what users are used to.

ICS File Import – If you receive an ICS file as an attachment, OWA cannot import this into your calendar. Depending on your communication partners, this could be a big issue. I generally don’t see ICS files aside from registering for webinars or from our travel reservations system.

Conversation View – The “Conversation View” feature seems to be one that users either love or hate. Personally, I’m not a big fan of the view and OWA does provide an option for users to disable it. Unfortunately, disabling Conversation View is a “per-folder” setting and has to be done on each folder.

Email Signatures – While I tend to keep the content in my email signature pretty limited, it’s not uncommon for users to want to put some type of image in their signature. You can argue that this is just cluttering up mailboxes but it’s something that people are used to doing in Outlook. In OWA, you can’t simply paste an image into the signature, it needs to be a link to an image with an externally accessible URL. I have seen some mixed results with this one where you can paste the image in the signature but then it doesn’t send properly for some reason.

Pasting of Images – Pasting images from the clipboard into the body of a message in OWA can also be a bit hit or miss. It seems to be dependent upon the source content. Otherwise you can use the option to import an image from a file but when you’re used to pasting screenshots directly, saving to file first and importing is far from efficient.

Public Folder Coexistence – If you’re running in an Exchange Hybrid environment with Public Folders on-premises made accessible to cloud users, you should be aware that these cannot be accessed via OWA.

Retention Policy Tags – If you use Personal Tags in your Retention Policy, users will not see these tags by default within the right-click menu. The user will need to go to “Options” | “Mail” | “Automatic Processing” | “Retention Policies” and then select the tags they want added to the right-click menu.

Access to PSTs – No one wants to acknowledge that they have PSTs in their environment but it’s almost always the case that they do. Users will have PSTs and if you take away Outlook, they no longer have a way to access them. Microsoft does have an option to import the PSTs into the mailbox or archive mailbox (see: Using the New PST Import Service) but there is no way within OWA to access them.

No “mailto:” Functionality – If you’re used to clicking on a hyperlink to an email address on a website, in a document, etc, that functionality won’t work when you’re using OWA. In fact, the OS will likely want to launch your default email application which could be assigned as the built-in mail client.

Third Party Add-Ins – This will be come less of an issue as vendors begin to adopt the “Office Add-Ins” model that works universally with Outlook, OWA and eventually the mobile client. If you use an application today that has a client-side installation (e.g. WebEx), that functionality will be missing in OWA.

Summary

Despite the above list of differences, it doesn’t mean that OWA can’t become your primary mail client. Each user is going to have different usage requirements and different levels of tolerance to change. In many cases, the same tasks can be achieved but in a different way. Fortunately, it’s easy enough to pilot given that everyone will have access to the OWA interface as soon as they have a mailbox.

Take some time and try it yourself! Force yourself to use OWA exclusively for a week; leave a comment if you come across any other limitations.

Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.


Office 365 – Can OWA Be A Replacement For Outlook? was first posted on September 8, 2015 at 10:00 am.

Office 365 – Why You Should Be Using The “Service Admin” Role

$
0
0

When it comes to security “best practices” there are some that are debatable and others that are fairly well accepted. One that is difficult to argue against is that administrators should maintain an account with elevated access that is separate from their day-to-day user account (see note at the bottom for a possible argument against this “difficult to argue” point).

For Office 365, there are a number of roles available with varied level of elevated access. Despite this, I still see many administrators with their “user” account assigned the “Global Administrator” role. In the Office 365 realm, this role has more privileges than a “Domain Admin” would typically have in the on-premises environment. A “Global Admin” account, if compromised, could certainly do some dastardly things.

One role that I rarely see used is the “Service Administrator” role. By definition, this role can “manage service requests and monitor service health”. When you look at the permissions the “Service Administrator” has, it’s not much. It can basically view user information and open support tickets.

What you do get with the “Service Administrator” role is the ability to view the current health of your tenant via the dashboard. Additionally, I have seen Microsoft send notifications to the “Service Administrator” role such as the notification discussed in this post: “Microsoft’s Proactive Notification of User Issues“.

Since you’re likely logging into the Office 365 portal daily with your “user” account (to access email, OneDrive for Business, SharePoint Online), it can be beneficial to be able to see the service health or other important alerts such as an expiring AD FS certificate (like below) as part of your daily activity.

Adding your “day-to-day” user account to the “Service Administrators” role provides the benefit of increased awareness with minimal additional elevated privileges to be concerned about.

As for your “Global Administrator” account, I would love to say that we should enable multi-factor authentication (MFA) for this account. Unfortunately, Remote PowerShell doesn’t currently work with MFA and if you’re using your admin account, you’re probably using PowerShell at least half the time. Hopefully this will change in the future, in the meantime, protect it as much as possible with a secure password.

Additional Thoughts…
As my colleague Allan Bourne pointed out, “Just In Time Access” is quite possibly the future replacement for maintaining a secondary admin account. Azure AD has such functionality available in preview, check out “Azure AD Privileged Identity Management” for more information.

Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – Why You Should Be Using The “Service Admin” Role was first posted on September 14, 2015 at 10:00 am.

How Is The Office 2016 Release Relevant To My Office 365 Users?

$
0
0

On September 22nd, Microsoft announced the release of Office 2016. The latest version of the Office suite, as you can imagine, brings with it a number of new features. In addition to the new features, Office 2016 will be deployed to users with a new deployment strategy for those using the “click-to-run” installations.

New Version!
New Features!
New Deployment Strategy!

 
So what does this mean for your Office 365 users that are currently running the Office 2013 version of Office ProPlus?

Deployment Overview

Before we talk about some of the new features available in Office 2016, let’s first talk about how and when your users will see it. The click-to-run (C2R) installation of Office 2016 now has the concept of “update branches” which allow for the separation of feature updates from security updates.

Update Branches
There are three update branches for Office 365 ProPlus users:

  • Current Branch
  • Current Branch for Business
  • First Release for Current Branch for Business
The differences in these branches is in how often users receive feature updates. Whereas all three branches receive monthly security updates, feature updates are monthly in “Current Branch” but every four months in “Current Branch for Business” and “First Release for Current Branch for Business”. The idea around the “First Release” branch is that it’s 4 months ahead of the default “Current Branch for Business” and thus gives you time to test compatibility.

Version Support
Microsoft is following an N-1 support model for Office 2016 and will support the current “Current Branch for Business” version and one version back. Beyond the N-1 version, security updates will not be received; this essentially gives you a maximum of 8 months of support for an individual version.

How Do I Control My “Update Branch”?
The default branch for Office 365 ProPlus users is “Current Branch for Business” and the branch used by your users can be controlled via the Office Deployment Tool or Group Policy Administrative Templates.

If you’re not ready to update to Office 2016 when Current Branch for Business starts rolling in February 2016, check out “How do I stay on Office ProPlus 2013“.

How Do I Get It Now?
You can give users the ability to download and install Office 2016 today by enabling them for “First Release”. Once enabled, they will see two Office download options in their download page.

What to Watch For…

Okay, we’re almost to the features but before we deploy Office 2016, there are a few things we need to watch out for. Microsoft has done a good job outlining some of these things on the site “Prepare to update Office 365 ProPlus to the Office 2016 version“. I’ve also expanded on a few of them in a previous article: “Using Office ProPlus? Take Caution Upgrading To 2016“.

Most important is probably to pay attention to the potential network impact if you are allowing users to install directly from the Internet. You may want to consider using the Office Deployment Tool to have users install from an on-premises file repository.

New Features!

Office 2016 seems to have a focus on enablement through the cloud and collaboration. While others can probably speak better about the Power BI integrations into Excel or the exciting co-authoring features in Word, my focus is on Outlook.
Cloud Attachments
This is the one that is most exciting for me. While the functionality has existed in the OWA interface for a bit, it’s now natively available in Outlook. We can now start using OneDrive for Business more efficiently by sending a link to a file instead of sending the attachment. When sending the link, the security permissions are set on the file based on the Outlook recipients.

Office 365 Groups
Another feature that first appeared in OWA, Office 365 Groups, are now available in Outlook 2016. The ability to create and access Office 365 Groups is right in the folder pane along with your other email folders.

Mailbox Cache Slider Improvements
Outlook 2013 was the first appearance of the “Sync Slider” that allowed you to control the amount of mailbox being cached locally. Instead of caching the entire mailbox, you could sync as little as 30 days. In Outlook 2016, even more flexibility is available and now you can cache as little as 3 days of email. This can be helpful in certain types of mail migrations where caching of the mailbox is unavoidable.

Keep in mind some of these features will be dependent upon settings configured in the tenant. If you’ve disabled external sharing of OneDrive for Business content or disabled Office 365 Groups, some of the above functionality will not work.

But Wait! There’s More!

Included in the announcement of Office 2016 was mention of a couple Office 365 features that have not yet been released but will be coming soon:
Office 365 Planner” is a collaboration tool expected later this year that seems to combine many of the great features in Office 365 like Delve and Office 365 Groups.

Microsoft “GigJam” is another tool that will become part of Office 365 next year and offers a very unique way to collaborate.

As is the case with Office 365, there’s always more functionality on the horizon!


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.


How Is The Office 2016 Release Relevant To My Office 365 Users? was first posted on September 24, 2015 at 10:00 am.

Office 365 – Excel Tips For Mail Migration Data Manipulation

$
0
0

While a good percentage of my mail migrations are part of an Exchange Hybrid environment, I don’t always have that luxury. We still work with plenty of migrations to Office 365 from non-Hybrid environments, each with different migration toolsets.

When you get to a migration that is something like Google, Zimbra or even an Office 365 “tenant to tenant” migration, Microsoft Excel becomes part of your migration tools. These types of migrations are full of CSV exports from multiple sources and manipulation of these exports with various formulas. While some might argue that this data should be put into a database instead of spreadsheets, I generally don’t have access to a DBA and Excel offers more agility in manipulating the data.

Below are some of the Excel tricks that I use when managing this data.

History of the Spreadsheet

Stepping back a bit, the idea for this article came from a podcast that I was listening to on the origin of the electronic spreadsheet; at that time I happen to be sorting through massive amounts of data on spreadsheets from a sizable Office 365 tenant to tenant migration. The podcast was from NPR’s “Planet Money” and I’d recommend giving it a listen:

The Tricks

I’m sure that others have some tips and tricks that I haven’t thought of here or used before; if you have any others, drop a note in the comments and I’ll add them into the list. I’m by no means an Excel expert but the items below are some relatively simple tools that I often reach for.

Count

Pretty much the first thing I do with any spreadsheet that has a list of users, mailboxes, etc is get a count of the number of items. I want this to be dynamic as I filter through different aspects of the spreadsheet.

So in cell “A1” I enter the following (assuming that column B is fully populated):

=SUBTOTAL(3,B:B)-1

This gives me a nice dynamic count of my rows:

Filter

My second step is usually enabling filtering on the sheet. This is of course assuming we have the data we want to filter in a format to do so. Just highlight the columns you want to filter on and press “CTRL+SHIFT+L” or select the “Filter” button in the ribbon.

We can now filter on a values such as whether or not the user has an archive mailbox (and our “count” in A1 will update accordingly).

Dissecting Email Addresses

Sometimes you need to separate an email address into two parts: the user and the email domain. Perhaps you need to generate an address with a new email domain for everyone. There are a couple of ways to do this.

You can use the “Text to Columns” feature within Excel and split the column using the “@” as the delimiter. This will want to overwrite the neighboring column and modifies your source data which I often try to avoid.

Another option is to add a new column and use this formula to extract the user (cell C2 below):

=LEFT(B2,FIND("@",B2)-1)

or this formula to extract the SMTP domain (cell D2 below):

=RIGHT(B2,LEN(B2)-FIND("@",B2)))

VLOOKUP

The VLOOKUP function will quickly become your friend in Excel; knowing how to use it properly will be critical. The idea is that you can take a value and see if it’s in a column on another sheet; if it’s found, you can return a value from the row where the searched value was found. Since this one is a little more complex, you might also want to check the Microsoft syntax on this function.

I’ll often use this in situations where I’m comparing source and target mailbox lists or perhaps comparing a list of users against a list of migrations and their statuses.

In the example below, I have two sheets: “UsersToMigrate” and “MigrationStatus”. The “UsersToMigrate” would typically be a list I’ve exported out of the source environment and “MigrationStatus” would be similar to a report you might export out of a tool like “MigrationWiz”.

In cell C2 of “UsersToMigrate”, I’ve entered the following formula:

=VLOOKUP(B2,MigrationStatus!A:B,2,FALSE)

Basically I’m looking for B2 in column A of the “MigrationStatus” sheet and then returning the value in the second column (column B) of that row. Critical here is the use of the “FALSE” flag; if you don’t use this, the default is “TRUE” which looks for the closest result and not necessarily an exact match.

VLOOKUP as Boolean

Occasionally you’re using the above formula against a dataset that doesn’t necessarily contain all the values we’re searching on; values not found will come back as “#N/A”. Maybe we just want to know if the value in B2 exists in the “MigrationStatus” sheet and treat it as a Boolean.

We can do this with the formula:

=ISTEXT(VLOOKUP(B2,MigrationStatus!A:A,1,FALSE))

This will return “TRUE” or “FALSE” and then we can easily use the filters to find out how many have been found.

Summary

Certain types of mail migrations result in data being managed through a series of exported CSVs. Functions within Excel can be used to make sorting through the data manageable and allow you to compare values between multiple data sources.


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.

Office 365 – Excel Tips For Mail Migration Data Manipulation was first posted on October 1, 2015 at 10:00 am.

Script For Generating Mailbox Test Data Over A Period Of Time

$
0
0

Just a quick but helpful script today for generating mailbox test data. While there are other scripts available that can send test emails to populate a mailbox, in some instances you need those emails to be spread out over a span of time.

If you want to test out archiving, retention policies, OST caching or any other date-sensitive operation, a mailbox full of test data from the day prior is not that helpful.

In the script below, you can populate a test mailbox with emails going back X number of days with Y number of emails per day.


Some Influences…

Some of the code in this script was inspired by examples from Glen Scales and Mike Pfeiffer. Glen is pretty well known as the go-to for all things EWS API related and Mike has a nice script for generating lab mailboxes.

Prerequisites

This script uses version 2.2 of the EWS Managed API. If you don’t have it installed, you can download it from Microsoft: Microsoft Exchange Web Services Managed API 2.2. The API should install in a default folder of “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”, if you install it in a different location you will want to modify the script or use the command line parameter to specify the alternate location.

You will also need an account that is setup for Impersonation. If you don’t have an account with this role, you can easily set it up with these instructions: “How To: Configure Impersonation“.

Using The Script

The script takes up to eight command line switches although you can specify as few as one. The parameters are as follows:
TargetMailbox
The SMTP address for the mailbox that you want to populate.

NumDaysBack
The number of days back from the current date to start populating messages. Default value is 120 days.

MsgsPerDay
The number of messages to create for each day. Default value is 5 messages per day.

MsgSize
The size of the attachment for the message. Default value is 100kb.

AutoD
If specified as $True, Autodiscover is used to determine the EWS endpoint. Default value is $True.

EwsUri
EWS endpoint for target mailbox. Default value is to use Office 365 if not using Autodiscover.

ApiPath
Location of EWS API. Default path is “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”.

Version
Exchange version to be used by EWS. Default is “Exchange2013_SP1” and likely does not need to be changed unless you’re using an earlier version of Exchange. Acceptable options are documented at “EWS schema versions in Exchange“.

So using the following would give us a mailbox with 3 years of email where there are 10 messages per day of 200 KB each:

.\Populate-TestMailbox.ps1 -TargetMailbox test.user@iwitl.com -NumDaysBack 1095 -MsgsPerDay 10 -MsgSize 200kb

When executing the script, you’ll be prompted for the credentials of the account that has the Impersonation role.

Note

It should be noted that this script does not actually “send” emails as you cannot send the email and fake the date; instead, it creates emails and saves them into the Inbox folder. I have not noticed any difference in the operation of functions like retention policies or OST caching but it’s something to watch for.

Download

The script for this post can be found in the Microsoft Script Center at the following link: Populate-TestMaiboxByDate.ps1


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Script For Generating Mailbox Test Data Over A Period Of Time was first posted on October 12, 2015 at 10:00 am.

Office 365 – Azure AD Connect: Did You Know?

$
0
0

brain_gears_shutterstock_wordpressAzure AD Connect is the synchronization tool formerly known as “Azure AD Sync” which was formerly known as “DirSync”. Regardless of what you call it, Azure AD Connect is the tool you’ll use to synchronize your on-premises Active Directory with Azure AD.

With each name change, new features have been added to the product.

Below are 10 quick little tidbits you might not have known about Azure AD Connect.

1: Where To Download

For reasons unknown, if you follow the links in the Office 365 portal to setup Directory Synchronization, you will be sent to a download link for the old version of DirSync (the version two names ago). Download the current version of Azure AD Connect from this link: Azure AD Connect.

2: Configuration Options

During the initial configuration, you’ll be presented the option to use the “Express” or “Custom” installation. While “Express” is designed to make installation easier (and can even configure AD FS for you), I prefer to maintain control over the configuration and always select the “Custom” option.

3: Cloud Service Account

During the custom installation, you’ll be prompted for “Global Admin” cloud credentials for your tenant. If you’ve installed any of the previous versions, you might think that these are the credentials used by the synchronization engine; they are actually used by the installer to create a service account. Previously you needed to create the cloud service account yourself and set the password as non-expiring. In Azure AD Connect, the installer will create an account in the tenant called “Sync_SERVERNAME_GUID@tenant.onmicrosoft.com”. The account will have a non-expiring password and have a custom role (“Directory Synchronization Accounts”) so that it’s not a “Global Admin”. Interestingly, it will also show as a synchronized account despite appearing to be a cloud account.

4: On-Premises Permissions

With the custom installation, Azure AD Connect does not configure any of the necessary permissions in the on-premises Active Directory. The permissions needed will depend on what sync scenarios you are using such as Password Synchronization, Exchange Hybrid, Password Writeback, etc. The list of permissions can be found at: “Permissions Required for Specific Scenario“. There are a number of scripts available that can configure these permissions, Brian Reid has one of the more well documented ones.

5: Schema

If you’re installing in a clean environment such as a lab, you’ll want to make sure that you have the Active Directory schema in place before configuring Azure AD Connect. If Azure AD Connect does not see the Exchange schema, it will not allow you to select the Exchange Hybrid write-back scenario.

6: Deleted Item Threshold

Azure AD Connect includes a feature to help prevent accidental mass deletion of cloud objects. By default, you cannot delete more than 500 objects via a sync operation. Depending on the size of your organization, you might want to lower this number or you may need to disable it temporarily when clearing out a tenant. Changes to this setting can be done via the relatively undocumented PowerShell module, run “Import-Module ADSync” from the Azure AD Connect server to access the commands. Additional information on the threshold and on how to change it can be found at: “Prevent Accidental Deletes“.

7: Piloting

Azure AD Connect includes a nice feature that allows you to pilot the sync process before synchronizing the entire directory. Previously you would have to put filters in to select your pilot users but now you can select a group and Azure AD Connect will only sync objects in that group. Once you’re done piloting, you can run the configuration wizard again to remove the pilot group restriction.

8: Staging

The last option during the configuration is to “Enable Staging Mode”. This allows you to perform the import operations and bring the data into the metaverse but it will not export out any changes to Azure AD or your on-premises Active Directory. In the situation where you’re transitioning from an old sync installation or want to test out your filtering, this is a nice option.

9: Filtering By OU

While filtering the objects you synchronize by OU is an option, it creates some complexities. If you get need to add additional OUs to the scope of objects that you want to sync, you will need to run a “full sync” in order for the new objects to sync. In large environments, a full sync can be a fairly time consuming process. Consider using a different filter method such as filtering by an attribute or try to keep your OU selections to higher level root OUs.

10: Stay Updated

While Azure AD Connect pretty much just runs and sends you an email report when there are sync issues, it’s not completely maintenance free. Six months into the product and we’re on the third version already. The updates generally contain a healthy set of fixes as well as new features. Make sure you check out the “Azure AD Connect Version History” page to see the latest updates. Fortunately, most updates can be done in-place with relatively little work.


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.


Office 365 – Azure AD Connect: Did You Know? was first posted on November 23, 2015 at 10:00 am.

Office 365 – Getting Closer To “True” Single Sign-On For Outlook

$
0
0

One of the Office 365 concepts that gets glossed over a bit is “single sign-on”, in particular when it comes to Outlook. Many will provide the statement that if you implement AD FS, then you have single sign-on.

While it is true that AD FS provides single sign-on for some workloads, I’ve often argued that Outlook, possibly the most popular application used with Office 365, is not single sign-on under any scenario.

Last week Microsoft somewhat quietly updated documentation around “Modern Authentication” which gets us closer to “true” single sign-on.

Below is a link-filled overview of Modern Authentication and how it gets us closer to “true” single sign-on…

Why Outlook Isn’t Single Sign-On Today

In the current process, a user launches Outlook and is prompted for his/her Office 365 credentials. This is because Outlook is actually doing “basic authentication” to Office 365 and if you look at the traffic flows, Exchange Online is authenticating to your on-premises AD FS on behalf of the user. After the user enters the login and password, there is an option to “save” the credentials using the Windows credential manager. So upon the next launch of Outlook, the user is not prompted for credentials again but it is because the credentials are stored. The user will have “reduced sign-on” until the next password change at which point the saved credentials are no longer valid.

I refuse to accept that saving credentials in the credential manager is true “single sign-on”, especially given that you’ve entered your login more than once (seemingly breaking the definition of “single”).

An additional difficulty with the current authentication process is that it doesn’t allow for a good way to implement multi-factor authentication (MFA). So instead of being able to use the Azure Multi-Factor Authentication feature, your only option is the stop-gap “App Passwords” feature which is far from great.

Modern Authentication

Going back to early 2014, we’ve been hearing about “Modern Authentication” and how it will solve some of the above issues. In the past year or so, updates have been announced where the service side was being updated or the clients were being updated. Initially, the list of incompatibilities was pretty lengthy but it’s since been reduced significantly. In March 2015, a public preview was announced and now the functionality can be enabled on your own and comes with production support.

Enabling Modern Authentication

It appears that Modern Authentication is enabled per-workload in Office 365. SharePoint Online is enabled by default, Exchange Online can be enabled by tenant administrators and Skype for Business requires a ticket to Microsoft. On the client side, Office 2016 will use Modern Authentication as first priority and Office 2013 will require a registry change to make it priority. If you’re using AD FS, you’ll want to check out KB3052203 for some additional configuration items. If you’re using AD FS claims, you’ll want to understand how Modern Authentication will impact those rules.

Some Things To Watch Out For

Important to understand is how the token refresh works with Modern Authentication. While the article “Session Timeouts for Office 365” provides a decent overview on the token process, there are some details missing. The article “Frequently Asked Questions about Modern Authentication in Office 2013” provides some important details such as:

  • The refresh token may be valid up to 90 days
  • A user that acquired a refresh token on the corporate network and then goes off-network will maintain a valid refresh token
  • Federated password changes do not invalidate the refresh token
  • MFA prompts will not reoccur on a device until the refresh token is invalid

So in the current implementation, it doesn’t look like MFA prompts and the token refresh may be as controlled as people might expect. As with any Office 365 feature, wait a bit and it will improve…

Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.


Office 365 – Getting Closer To “True” Single Sign-On For Outlook was first posted on November 24, 2015 at 1:00 am.

Office 365 – Better Ways to Schedule Meetings w/ External Parties

$
0
0

When it come to scheduling meetings with external parties, it seems like we fail to leverage technology more times than not. While there are several options available to make scheduling meetings easier, we almost always fail back to the default “what times work for you” conversations. This is everyone, I see it with clients, with our own company, even when scheduling meetings with Microsoft employees.

Perhaps one of the poorly communicated aspects of Microsoft Exchange / Office 365 is how much easier you can make scheduling meetings with attendees from outside your organization.

Below are three options (including one new one) that can help eliminate the “what times work for you” conversations…

Option #1: Organization Relationships

This first option will require involvement of both your IT staff and the external parties; the other options will be more suitable for more ad-hoc meetings. This is most suitable in situations where you have a long-standing relationship with the other attendees and provides for the most similar experience to scheduling time with internal employees.

Going back to Exchange 2010, we have had the option to use the “Microsoft Federation Gateway” and “Organization Relationships”. In a matter of a few minutes, your IT staff can create an organization relationship create an organization relationship between your organization and the external party. From there, you can schedule the external party just like anyone internal. Depending on the permissions allowed, you’ll see just the external attendee’s free/busy information or more if allowed.

Option #2: Calendar Publishing

Without seeking assistance from your internal IT, you can publish your calendar via a URL and allow external parties to see your availability. While your IT admins can disable this feature, it’s enabled by default. Within Outlook or OWA, you can select the option to “Publish Your Calendar” with access from “Availability Only” to “Full Details”. Once published, you can send external parties the URL or they can subscribe to it via ICS.
Note: While this is the option I most commonly use, it seems to have a small nuance you should be aware of. I’m in the EST time zone and the URL that I provide to others has all the calendar entries in EST. So parties outside of your time zone will need to do the conversion manually which can at times become a headache.


Option #3: Microsoft FindTime

Earlier this month, the Microsoft Garage released an interesting Outlook Add-In called “Microsoft FindTime“.

Available to Office 365 users, the application allows you to send invite requests from Outlook to external parties (they do not need to be on Office 365) and the attendees can “vote” on the meeting time. When sending the meeting request, you pick the duration and some prospective time slots; after selecting the time slots, they are all marked as “tentative” in your own calendar. The external attendees receive an email explaining FindTime and a link that allows them to mark a particular slot as “preferred” as well as acceptable or unacceptable.

Once the external attendees have voted, the meeting is automatically scheduled.

Summary

With varied levels of complexity and functionality, there are several options to assist with scheduling meetings with external parties. In all situations, the above options are better when it comes to trying to schedule a meeting with more than one external person.



Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – Better Ways to Schedule Meetings w/ External Parties was first posted on November 30, 2015 at 9:30 am.

Office 365 – SPF, DKIM and DMARC in Exchange Online (Part 1 of 2)

$
0
0

The fight against email spam is an on-going battle for mail administrators and while cluttering up a mailbox with junk mail is undesirable, phishing campaigns can be a serious security issue. Those with malicious intent are highly motivated and their practices have evolved over the years; fortunately, the technologies available to protect against such attempts have equally improved.

There are several technologies that can help your organization validate that an email has been sent from an authorized source. Office 365 expanded its support for some of these technologies earlier this year however it seems like these features get very little talk.

You’ve likely heard of SPF but what about DKIM and DMARC? Should you be implementing these?

Part 1 of this series will summarize these technologies and discuss how each builds on one another. Part 2 will get into the actual configuration in Exchange Online and some of the things you’ll want to watch for.

In the article below, I’ll provide an overview of what the three technologies are, how they provide different types of protection and how they can work together.

SPF (Sender Policy Framework)

SPF is pretty well known and commonly implemented. If you’re not familiar with SPF, it’s essentially a DNS record (TXT) that contains a list of approved senders by IP address, domain name or some other mechanism.

With Exchange Online, Microsoft provides you the information to properly configure your SPF record. However, if you have third-party services sending on your behalf, you may need to customize the provided value. There are some limitations on the number of DNS queries you can have in your SPF record and it’s not uncommon to see syntax errors so you should always validate your SPF record with one of the online validation tools.

If a message is received from a source not authorized in the SPF record, you as the receiving party can do what you choose with that information. You may decide to block the message, you might rank it higher as prospective spam or you could ignore it.

What Does Is Protect?
SPF looks as the “Mail From” field within an email and compares the sending IP address to the published TXT record for that domain. Important to understand here is that the “Mail From” field can contain a different value than the “From” or “Reply To” fields. This is how some phishing emails can enter your organization as they will have a valid SPF published for the “Mail From” and then present the user with a different email in the “From” field.

DKIM (DomainKeys Identified Mail)

DKIM uses a public/private key to sign messages as opposed to the published TXT record. One advantage of DKIM over SPF is there is no limit to the number of partners you can authorize to send on your behalf (assuming they support DKIM). If you use a number of third-party senders, you likely have run into issues of when trying to include them in your SPF. Another way to address the SPF limitation is to have senders send their messages under a subdomain and publish a separate SPF for that subdomain.

What Does Is Protect?
DKIM is also looking at the “Mail From” field and will show a “None”, “Pass” or “Fail” once the message has been evaluated. The same potential phishing issue exists with DKIM where the “Mail From” does not necessarily match the “From” field that the user sees.

What is… DMARC?

For DMARC, a DNS TXT record is created (_dmarc.company.com) and for mail systems that use DMARC, they will send success/failure reports to the addresses specified in the TXT record. A third-party tool or service can be used to aggregate these reports and analyze them.

DMARC, among other things, can be the answer to the above phishing issue. DMARC looks for a passed SPF or DKIM but also looks for “alignment” of the “Mail From” and “From” fields. Additionally, your configuration of DMARC allows you to tell recipient mail servers what to do with a message if DMARC fails.

Configuration

In part 2 of this article, I’ll get into the configuration of SPF, DKIM and DMARC in Office 365 and cover some of the nuances you need to be aware.


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – SPF, DKIM and DMARC in Exchange Online (Part 1 of 2) was first posted on December 7, 2015 at 9:00 am.

Office 365 – Using The New Advanced Threat Protection Feature

$
0
0

Back in April 2015, Microsoft announced their new Exchange Online “Advanced Threat Protection” (ATP) feature. A month later, I saw it for the first time at the Microsoft Ignite conference and it looked like something well worth checking out later.

Microsoft later made it available as a purchased add-on for existing licenses and released a few posts demonstrating the feature. I haven’t come across clients that went for the add-on option but I suspect we’ll be seeing more subscriptions with this functionality soon.

Among the many features included in the new E5 licenses is ATP. With the release of the E5 licenses last week, I took the time to check out ATP myself.

Below are some notes from that experience…

Brief Overview

Advanced Threat Protection (ATP) is really two types of protection for inbound emails. The first, “Safe Attachments”, is a deeper inspection of message attachments including sandboxing of suspicious attachments. The second, “Safe Links”, provides real-time inspection of links within an email along with reporting of what users have clicked a particular link and who bypassed the security notification (if allowed).

How To Get It

As stated above, ATP is available as an add-on to your existing licensing on a per user basis for $2.00/month or it is included as part of the new E5 licensing.

Enabling ATP

You can enable ATP in your tenant today by purchasing the add-on, adding E5 trial licenses to your current subscription or working with your account rep to get a trial setup.

When I first assigned E5 licenses in my tenant, the ATP feature remained unchecked on my E5 user (even after checking it, it would uncheck again). I was still able to create a policies and use the feature; a few days later I noticed the license was now checked, YMMV. My experience has primarily been around the “Safe Links” functionality in ATP; for some examples of the “Safe Attachments” feature, check out the “More Info” links below.

Once enabled, you’ll see an “Advanced Threats” option within the Exchange Admin Center portal, this is where you will configure the policies and can see reports. You will also see a “URL Trace” option within the “Mail Flow” tab, this option allows you to search for activity related to Safe Links.

Within your Safe Links policy, there are very few options to configure. It’s basically whether you want URLs rewritten, if you want to track user clicks, if you want to allow users to bypass the security warning and what URLs should be excluded.

User Experience – Safe Links

With “Safe Links”, URLs within an email are “rewritten” similar to how a URL shortening service works (although these URLs are far from short). The text of the URL stays the same but the HTML link behind it is changed to one prefixed with something similar to “https://na01.safelinks.protection.outlook.com/” and some parameters such as “url”, “data” and “sdata” are appended to it. When a user clicks on a rewritten link, Microsoft evaluates what is behind that link before passing the user through to the actual URL. This is meant to mitigate situations where emails are sent out containing links that are okay at the time the email is sent but redirected to malicious content some time later when the email is sitting in the user’s Inbox.

If a link is suspicious, the user is prompted with this alert:

Assuming you’ve allowed users to bypass the warning, they can click “Continue to this website (not recommended)” to view the page. If you’re testing out ATP, you can use the URL “www.spamlink.contoso.com” in your testing to force this warning.

Some Nuances

There are a couple things about ATP that I suppose should be expected but found interesting:

1. Since the URLs are rewritten and done so with incredibly long strings, it becomes more difficult to discern when a URL is legitimate or not. While the source URL is embedded in the string, something like a phishing attempt pointing to a slightly modified URL is not as easy to see. Now this is part of what ATP is there to protect and it’s probably only your real power users that will notice this but it is an important point to communicate to users on what ATP is and what it’s doing.

2. This may seem obvious but once a URL is rewritten, the content of the email has been changed. That means if I forward that email to someone else, they’re going to get the same ATP Safe Links behavior whether they use Office 365 or not. The rewritten URLs do not require any authentication beyond what’s embedded in the link so the recipient receiving the forwarded email will still be able to click the link. I haven’t seen it occur yet but I could imagine some non-Microsoft mail system looking at the HTML link not matching the text could possibly flag it; this will be something to watch for.

3. Likewise, if you copy and paste a URL from your email, it copies the Safe Link. I’ve already seen some Microsoft blog posts where a Microsoft employee apparently copied the Safe Link out of their mailbox and the blog now has the Safe Link instead of the intended URL. Like the situation with forwarded emails, the links still work however from a reporting standpoint, each time someone clicks on the URL, it’s recorded as if the original Safe Link recipient clicked it.

Summary

Overall, I like the functionality provided by ATP and time will tell how successful the added protection is. The changing of content within an email has me a little concerned and it would be nice to know how long the rewritten URLs remain active for. Like most Office 365 features, I look forward to seeing how this one evolves and develops.

More Info

Exchange Online Advanced Threat Protection Service Description
Advanced Threat Protection in Exchange: New Tools to Stop Unknown Attacks


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – Using The New Advanced Threat Protection Feature was first posted on December 9, 2015 at 9:00 am.

Office 365 – SPF, DKIM and DMARC in Exchange Online (Part 2 of 2)

$
0
0

The fight against email spam is an on-going battle for mail administrators and while cluttering up a mailbox with junk mail is undesirable, phishing campaigns can be a serious security issue. Those with malicious intent are highly motivated and their practices have evolved over the years; fortunately, the technologies available to protect against such attempts have equally improved.

There are several technologies that can help your organization validate that an email has been sent from an authorized source. Office 365 expanded its support for some of these technologies earlier this year however it seems like these features get very little talk.

You’ve likely heard of SPF but what about DKIM and DMARC? Should you be implementing these?

Part 1 of this series provided a summary of these technologies and discussed how each builds on one another.

In Part 2 below, I’ll get into the actual configuration in Exchange Online and some of the things you’ll want to watch for.

SPF

The SPF record is created as a DNS “TXT” record within the root of your DNS zone. If you’re using Exchange Online, Microsoft provides a starting point of the value for your SPF but it will likely need to be customized.

The default value listed in your tenant will be:

v=spf1 include:spf.protection.outlook.com -all


This value will work if you’re only sending messages out of Exchange Online and have no on-premises infrastructure relaying messages. If you have other systems sending mail, you’ll want to make sure that you include these sources in your SPF record.

Common issues I see with SPF records are organizations that try to add more than one TXT record, add too many (>10) DNS queries within their SPF record or just have an improper syntax. There are a number of sites that can validate your SPF record including MxToolbox.

DKIM

Configuring DKIM signing in Exchange Online is relatively simple. You essentially need to create two DNS records and run three PowerShell commands for each of your SMTP domains.

First we need to determine the appropriate values for the DNS records. In the tenant, run the following command for each of your SMTP domains:

New-DkimSigningConfig -DomainName company.com -Enabled $False


Then run the following to get the values:

Get-DkimSigningConfig company.com | FL Domain, *CNAME


Now it’s time to create the two DNS records. You’ll create the following two CNAMEs using the output from the above command:

Host: selector1._domainkey
Points To: selector1-company-com._domainkey.company.onmicrosoft.com

Host: selector2._domainkey
Points To: selector2-company-com._domainkey.company.onmicrosoft.com

Once the DNS records have propagated, return to PowerShell and run:

Set-DkimSigningConfig company.com -Enabled $True


You’ll soon start to see that your messages now show as DKIM signed in the message headers.

DMARC

Once you have SPF and DKIM properly configured, you may choose to start using DMARC. Configuration of DMARC involves the creation of a DNS TXT record to advise recipients of what to do with DMARC failures and where to send the DMARC reports.

You’ll likely want to start with an action of “none” meaning that you just want to monitor emails not but take any action. Even if you can’t get to the point where you configure an action of “quarantine” or “reject”, you can still use DMARC to help mitigate phishing attempts.

After determining the action type, you will probably want to use a third-party service to help analyze the DMARC reports. Your published DMARC record will tell recipients that support DMARC to email reports to the address specified in the DNS record. These reports will arrive as a compressed attachment containing an XML file. There are a number of services that can assist with analyzing DMARC reports, some that are free, some that are paid and many that have 30-day trials. For my low-volume testing, I used “dmarcian” but there are a number of others listed at “dmarc.org“. These services will usually provide you two email addresses to publish: one for the aggregate reports and one for failure reports.

Now it’s time to publish your DMARC record. This record is a TXT record but instead of being at the root like your SPF, the record will have a host name of “_dmarc”. Some DNS providers do not support hostnames that begin with an underscore in which case you may need to switch DNS providers if you want to configure DMARC.

A typical DMARC record might look this this:

Host: _dmarc
TXT Value: "v=DMARC1; p=none; pct=100; rua=mailto:dmarc_aggr@dmarcservice.com; ruf=mailto:dmarc_fail@dmarcservice.com;"


Again, you should use one of the validation sites like “MxToolbox” to check your published DMARC record.

You will now start seeing reporting data appear in your DMARC analyzer service from recipient organizations that support DMARC. The data presented will vary depending your service but you should have the ability to see which emails are passing DMARC and which emails are failing.

Here is a sample report out of “dmarcian”:

In the above report I could see that some emails (in red) that had my domain as a source have failed DMARC and depending on the action published in my DMARC record, I can help advise the recipient on what to do with those messages. You can even drill down into those failures, why they failed and what IP they were sourced from.

Because we’re now testing for “alignment” of the “from” and “mail from” fields, you may find that “legitimate” emails sent by third-parties on your behalf are now failing DMARC. Configuring DMARC will help expose messages not being sent using best practices.

Using DMARC To Your Benefit

While it’s great that using DMARC has given recipients more information on whether you actually sent the email that shows your domain as a source, it would be nice to have it help us too. Even if our action type is set to “none”, we can configure a Transport Rule for emails that have our domain as a source and fail DMARC. This is how we can help prevent phishing attempts sent to our employees using our own SMTP domains. Terry Zink at Microsoft has this configuration and a few other notes regarding DMARC documented in the blog post “Using DMARC in Office 365“.

Keep in mind that this will be dependent upon your MX records pointing to EOP as opposed to any on-premises infrastructure. You will want to test out this configuration and possibly use “incident reports” to monitor what items the Transport Rule catches before setting it to drop messages; you’ll find that some items like NDRs and out of office replies may get caught.

Summary

Office 365 supports functionality beyond SPF to help others validate the messages sent using your domain. Utilizing features like DKIM and DMARC in addition to SPF can improve your email reputation and help assist with internal phishing attempts.


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – SPF, DKIM and DMARC in Exchange Online (Part 2 of 2) was first posted on December 14, 2015 at 9:00 am.

Office 365 – Why PowerShell Version Matters

$
0
0

Just a quick post today on a topic that is loosely related to Office 365 but certainly can be important…

It’s no secret that a good part of the management within Office 365 is done via PowerShell. Whether you’re writing the scripts yourself or downloading scripts from the “PowerShell for Office 365” site, you’re going to be using PowerShell pretty regularly.

In my role, I’m often testing some scripts in a lab environment before handing them over to a client to run. The expectation is that they should execute the same in product as they did in my lab.

But what happens when the script doesn’t product the same results in production?

Below is one little trick that should probably be a best practice for any scripts you’re handing off to someone else to run.

For the most part, different versions of PowerShell respond the same. Newer versions will always have additional features but if a command runs in two versions, it usually produces the same results.

I’ll occasionally get tripped up by someone running PowerShell 2.0, where “Export-Csv” does not have an “-append” switch, and you quickly hit a wall when that occurs.

What I don’t expect is to have a command run but produce different results.

Take for example the following:

PowerShell Version 2

PowerShell Version 3

So while PowerShell 2 did not return any assigned licenses, there were in fact licenses assigned to the user. Imagine if the next operation was to disable or delete any user without a license.

Are there other ways this command could be put together such that PowerShell 2 returns the same data? Absolutely. The point however is that a script run in a test environment under a different version of PowerShell can produce different results. And while I can advise my client of what version they “should” use to be consistent with my testing, that doesn’t always happen.

A quick solution is to add a “requires statement” in my script that forces a particular minimum version (the version I tested with).

This can easily be done by adding the following to your script:

#Requires -Version 3


Yes, the pound sign (#) is intentional there...

If a user tries to run the script in a version lower than 3.0, they will receive the following error:

That's it, just a simple statement that should probably be included in any code you're sharing. If you wanted to take it a step further, you could use other methods to ensure the script is run under the same exact version as you tested. Either way, something to think about when sharing or used shared scripts.

Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – Why PowerShell Version Matters was first posted on December 21, 2015 at 9:00 am.

Office 365 – A Look Back at Office 365 Blog Posts in 2015

$
0
0

As we wrap up 2015, I took a look back at my articles for the year and revisited the topics. This was my second year posting here on the Perficient blogs and I managed to more than double last year’s 21 posts with 45 new posts.

Quantity of posts is by no means the goal, I really strive to create original posts with content that I have not found elsewhere. A number of posts have been scrapped after finding out during my research that someone else has already covered the topic sufficiently.

My goal is always to give you something new and interesting to read.

Below is a summary of my 45 posts in 2015, all in one spot. I’m looking forward to what 2016 will bring and what Office 365 topics and issues we’ll encounter.

If Office 365 is of interest to you, there’s a number of ways to keep in touch:

  • Subscribe via my RSS feed using your favorite RSS reader (Outlook works…)
  • Leave a comment below (perhaps on a topic you’d like to see covered) which will allow you to subscribe via email.
  • Follow me on Twitter (@JoePalarchio); my feed is nearly 100% Office 365 content so you won’t see any rants about customer service issues or pictures of my most recent meal.

Thanks for reading!

See you in 2016!

Exchange Online

Office 365 – Five Exchange Online Tasks to Consider (Post-Setup)
Five quick things you might want to do after you’ve setup Exchange Online.

Office 365 – New Features Appear on the Office 365 Roadmap
New features at the time (January) although at least one has yet to make it to General Availability.

Office 365 – Watch Your “Recoverable Items Quota”!
Why the Recoverable Items Quota might be something to watch out for.

Office 365 – Common Exchange Online Hybrid Mail Flow Issues
Common issues I see with hybrid mail flow; I discuss why even when mail is actually flowing, it may not be working properly.

Office 365 – How to Update Address Lists in Exchange Online
There’s sort of a nuance (/bug?) with Address Lists in Exchange Online, I’ve put together a script to help address that issue.

Office 365 – Microsoft’s “Cloud-First” Strategy In Action
A couple of examples of how Exchange Online will always be ahead of on-premises Exchange when it comes to features.

Office 365 – The Magic Behind The Hybrid Config Wizard (2010)
All the commands run in your on-premises Exchange when running the Hybrid Configuration Wizard; hopefully making that process a bit less black box.

Office 365 – The Magic Behind The Hybrid Config Wizard (2013)
All the commands run in your on-premises Exchange when running the Hybrid Configuration Wizard; hopefully making that process a bit less black box.

Office 365 – Allowing Users to Edit Exchange Groups They Manage
A somewhat unique workaround for cloud users that need to manage on-premises distribution groups for environments with Exchange 2013 on-premises.

Office 365 – Using the New PST Import Service
An overview of how to use the PST Import Service. This post has had nearly 40,000 hits in a six-month period; people must really be interested in PSTs.

Exchange Hybrid – The Unspoken Limitations That You Should Know
I was fortunate to be able to speak at Microsoft Ignite in Chicago; this post contains the content from my session along with the slide deck.

Exchange Online – After the Migration… Now What?
The Microsoft Technology Center in Detroit hosted a post-Ignite event where I presented; this post has the content and slide deck from that session.

Office 365 – Is the “Archive Mailbox” Still Relevant?
Do we really need archive mailboxes anymore? How they often are used for the “wrong” reasons.

Office 365 – A Deeper Look at the Microsoft “Send” App
Microsoft Garage released a mobile app with an interesting an unique communication idea; this post digs into that application.

Office 365 – Common Confusion with Email Retention Policies
Becoming a more and more common topic with my clients, retention policies seem to be confusing to some. I’ve tried to help clear up some of that confusion.

Office 365 – Disabling MAPI Includes Unexpected Results
Some surprises when you disable MAPI on a mailbox.

Office 365 – Can OWA Be A Replacement For Outlook?
OWA is pretty functional, could you make the switch from Outlook? This post has a few things to know.

Office 365 – Excel Tips For Mail Migration Data Manipulation
A bunch of Excel tricks I use when sorting through exports of users lists and mailboxes.

Script For Generating Mailbox Test Data Over A Period Of Time
Test mailboxes often lack good test data, I created a script that can populate a mailbox with data that spans a specified date range.

Office 365 – Getting Closer To “True” Single Sign-On For Outlook
An overview of what “Modern Authentication” is and what it will change.

Office 365 – Better Ways to Schedule Meetings w/ External Parties
How you can share calendars with external parties to ease in scheduling meetings.

Office 365 – SPF, DKIM and DMARC in Exchange Online (Part 1 of 2)
An overview of three technologies available to help minimize spam and phishing attempts.

Office 365 – SPF, DKIM and DMARC in Exchange Online (Part 2 of 2)
How to configure SPF, DKIM and DMARC in Exchange Online.

Office 365 – Using The New Advanced Threat Protection Feature
Some notes on using the ATP feature available with E5 licensing.


Directory Sync / AD FS

Office 365 – How to Configure UPN Filtering in AADSync
How to configure AAD Sync to filter based on one or more UPN suffixes.

Office 365 – The Limitations of Alternate Login ID
Alternate Login seemed like a great idea when it was released but this post contains a list of issues and limitations that you should be aware of.

Office 365 – Azure AD Sync: Did You Know?
Some tips and tricks related to Azure AD Sync.

Office 365 – How to Request a SHA-2 Certificate in AD FS 3.0
You shouldn’t be using SHA-1 certificates and requesting SHA-2 certificates in AD FS 3.0 is a bit tricky; this post tells you how.

Office 365 – Why You Need to Understand ImmutableID
The title explains it all, learn it now as there’s almost no undoing it later.

Office 365 – Script to Change UPN between Federated Domains
You can’t change a user’s UPN suffix between two federated domains, this post has a script that will help.

Office 365 – Unable to Activate Directory Synchronization
Sort of an odd issue I encountered where you couldn’t enable Directory Sync in a tenant.

Office 365 – When to Consider a Third-Party Identity Provider
When it might make sense to use a third-party IdP over Azure AD.

Office 365 – Why Your UPN Should Match Your Primary SMTP Address
Why you’re going to cause you users pain if you don’t make their UPN the same as their email address.

Office 365 – Azure AD Connect: Did You Know?
Some tips and tricks related to the new Azure AD Connect.


Office ProPlus

Office 365 – Office ProPlus C2R Not Compatible With MSI Installs
Learn about some issues with C2R and MSI installations of Microsoft Office.

Office 365 – Using Office ProPlus? Take Caution Upgrading To 2016
Some things to be aware of with Office 2016.

How Is The Office 2016 Release Relevant To My Office 365 Users?
What you should know about Office 2016 as it pertains to Office 365.


Other

Office 365 – How To Update Your Azure AD PowerShell Module
Why and how to update it.

Office 365 – Microsoft’s Proactive Notification of User Issues
An interesting alert I received from Microsoft on users with outdated software.

Office 365 – Two Azure AD Premium Features Coming To All Subscribers
An overview of two features that were previously limited to Azure AD Premium which were released to all.

Office 365 – How to Handle Departed Users (Part 1 of 2)
What to do with Exchange Online users when they leave your organization.

Office 365 – How to Handle Departed Users (Part 2 of 2)
What to do with OneDrive for Business users when they leave your organization.

Office 365 – Efficiently Connecting to Office 365 Via PowerShell
If you’re copy and pasting commands to connect to Azure AD, you’ll want to read this article.

Office 365 – Why You Should Be Using The “Service Admin” Role
A role that isn’t commonly used but should be.

Office 365 – Why PowerShell Version Matters
How different versions of PowerShell can produce different results in your scripts and a simple command that can be added to avoid problems when sharing scripts.


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – A Look Back at Office 365 Blog Posts in 2015 was first posted on December 28, 2015 at 9:00 am.

Office 365 – SSL Certificate Maintenance Tasks To Plan For

$
0
0

It should come as no surprise that Office 365, being a secure service, has a number of SSL certificates in play. Some are owned and managed by Microsoft and some, depending on your on-premises components, are certificates that you are responsible for maintaining.

Failure to keep track of these certificates could result in an interruption of services.

Below are the various certificates that you should be aware of and how to manage them.

Active Directory Federation Services (AD FS)

If you use AD FS for authentication, there are two certificates that you need to be aware of:

Service Communications Certificate
You are likely aware of the SSL certificate that you purchased and assigned to your AD FS farm for authentication. This certificate, the “Service Communications” certificate, is installed on each internal AD FS server and each AD FS proxy server. The name on this certificate will be whatever you named your federation service (e.g. “sts.company.com”); if you’re using “Workplace Join” or “Azure Device Registration”, you will also have “enterpriseregistration.company.com” as a SAN on the certificate.

When your Service Communications certificate expires, you can use the following to renew it:

When renewing this certificate, if you’re currently using a SHA-1 certificate, you’ll want to switch to SHA-2. To generate a SHA-2 CSR on Windows Server 2012 R2 (AD FS 3.0), you can use this process: Office 365 – How to Request a SHA-2 Certificate in AD FS 3.0

Token-Signing & Decryption/Encryption
By default, AD FS uses a self-signed certificate for token-signing and token-decryption/encryption. This certificate has a default expiration of 1-year but can easily be extended and I generally recommend doing so. While the certificate will automatically renew, the trust with Office 365 will need to be updated; failure to update the trust will result in an inability to authenticate to Office 365 via AD FS. Microsoft will provide alerts in the tenant regarding an upcoming certificate expiration however you should proactively be aware of the expiration and plan for it.

Note: While the Microsoft recommendation for Office 365 is to use the self-signed certificate, some organizations will choose to use their own publically trusted certificate for token-signing and decryption/encryption. This tends to be the case when additional applications are leveraging AD FS; if you have this configuration, the instructions below do not apply to you.


To extend the expiration of the self-signed certificate, you can use the following commands on the primary AD FS server using the AD FS and Azure AD PowerShell module:

Set-AdfsProperties -CertificateDuration 1095
Update-AdfsCertificate –Urgent

Connect-MsolService
Update-MSOLFederatedDomain -DomainName: company.com -SupportMultiDomain

The above will set the certificate to expire 1,095 days from now. You may want to consider aligning this with the expiration of your Service Communications certificate so the renewal is a coordinated event. You could also extend this out 5+ years if you’re comfortable with that; odds are you will have upgraded your AD FS by then.

When the expiration is coming up, you’ll start seeing a warning within the tenant. A new self-signed certificate will be generated 20 days prior to the expiration of the current one. Once that occurs, you will want to run the same commands as above to update Office 365.


Exchange Hybrid

If you’re running in an Exchange Hybrid configuration, you have a couple of areas to watch out for:

Federation Gateway
When you ran the Hybrid Configuration Wizard, a trust was setup with the Microsoft Federation Gateway so that you can establish an Organization Relationship between your on-premises Exchange and Exchange Online. This is the component that allows for you to share free/busy information between on-premises and the cloud (or with other organizations). When that trust was created, a self-signed certificate was generated with a 5-year expiration. While this certificate is fairly “self-maintaining”, problems can arise with it at times.

Occasionally I’ve seen where this certificate is not replicated throughout your environment, resulting in intermittent free/busy issues.

Additionally, you may run across a situation where the certificate or metadata has an issue. You can easily resolve this with the following command:

Get-FederationTrust | Set-FederationTrust –RefreshMetadata

Microsoft even recommends running this as a scheduled task in Exchange 2010 environments: Keep Your Federation Trust Up-To-Date

OAuth
In an Exchange 2013 environment, OAuth may have been configured between your on-premises Exchange and Office 365 depending on when you ran the Hybrid Configuration Wizard. This configuration uses a certificate with a 5-year expiration.

You can see the certificate in use with the following:

(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | FL

While there are manual instructions for configuring OAuth (Configure OAuth authentication between Exchange and Exchange Online organizations), I would recommend using the Hybrid Configuration Wizard to handle this renewal.

Client Access
The certificate installed on your on-premises Client Access Servers is still used by your Office 365 users. Your Autodiscover record will still be pointing to your on-premises Exchange and the EWS endpoint used for free/busy lookups will also be used. Assuming you’ve been running Exchange on-premises for any length of time, you’re familiar with the process of maintaining this certificate. If you deployed dedicated servers for the purpose of remote mailbox moves or for your hybrid implementation and those servers have a separate certificate and expiration, you’ll want to take note of that certificate.

Mail Transport
The one configuration item that is sometimes overlooked is when you’re running Exchange hybrid with Exchange 2013. The send/receive connectors between your on-premises Exchange and Exchange Online include details of your SSL certificate and will require updating when you renew that certificate.

You will see the certificate “Issuer” and “Subject” in these three places:

  • “TlsCertificateName” field in your on-premises “Default Frontend” receive connectors
  • “TlsCertificateName” field in your on-premises “Outbound to Office 365” send connector
  • “TlsSenderCertificateName” in your Inbound connector in your tenant

While you could use the Hybrid Configuration Wizard to update these values, you can also generate the appropriate string and populate them via PowerShell.

If you’re using Exchange Edge Transport servers, don’t forget about those servers.


Office 365 Mobile Device Management (MDM) / Intune

If you’ve setup Office 365 MDM or Microsoft Intune and have any iOS devices, you should have configured the Apple Push Notification Service (APNS). During that configuration, you acquired an APNS certificate from Apple and that certificate has an expiration of one year.

You need to proactively renew this certificate before it expires or you will need to enroll your devices again. While you may receive an email from Apple about the upcoming expiration, this is definitely one to keep track of.


Summary

All in one spot, here’s what you should have marked in your calendar:

ComponentCertificateExpirationNotes
AD FSService CommunicationsYou decide at purchase
AD FSToken-Signing
Token Decryption/Encryption
1 YearSelf-signed; expiration can be extended
Exchange HybridMicrosoft Federation Gateway5 YearsAutomatically renews
Exchange HybridOAuth5 YearsApplies to Exchange 2013/2016
Exchange HybridClient Access ServersYou decide at purchase
Exchange HybridMail TransportYou decide at purchaseApplies to Exchange 2013/2016
Office 365 MDM / IntuneApple Push Notification Service (APNS)1 YearProvided by Apple

Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – SSL Certificate Maintenance Tasks To Plan For was first posted on January 11, 2016 at 10:00 am.

Office 365 – What’s Your Office 365 “Secure Score”?

$
0
0

Part of the excitement of working with Office 365 is there is no shortage of new features being rolled out to keep your job interesting. As a consultant, it certainly keeps you on your toes and reminds you of the importance of continual education.

There are the features documented on the Office 365 Roadmap, features that are noted in the “Change Alerts” group in Yammer and then features that are little hidden gems that no one seems to be talking about.

I recently stumbled across one of these hidden gems called “Secure Score”.

What is “Secure Score”?

“Secure Score” appears to use a series of PowerShell scripts that gather configuration information from your Office 365 tenant; that data is then evaluated against various criteria to determine a “score” representing your security posture and recommendations on how to improve it.

Here’s the description from the site:

It’s like a credit score for your security. The Office 365 Secure Score is a new data service Microsoft is building to help our tenants understand the extent to which they have adopted robust security configurations, behaviors, and best practices. The experience places all of the existing security-relevant features of the service in one place and makes it easy to tell which things you have adopted or not, and then makes it easy to remediate the gap.


To some extent, it’s like the Microsoft Baseline Security Analyzer (MBSA) utility for Office 365.

How To Use It

First of all, it’s very clear from the site that this is a tool that is under development. The site states that the feature is “Alpha Preview” and to “Please understand that this service and software is a very early alpha and subject to issues”. That said, I always welcome the opportunity to check out bleeding edge features with the understanding that they will only get better.

You can access the “Secure Score” tool via the URL: https://o365securescore.azurewebsites.net/

The tool, in it’s current form, requires that you have the PowerShell modules for various components installed. So you’ll need the PowerShell modules for each of the following:

  • Azure AD
  • Azure
  • Azure RMS
  • Skype for Business
  • SharePoint Online
Fortunately, I already had these installed on my workstation but if you don’t, the “Secure Score” site and scripts will point you to the download links.

Once you have the prerequisites installed, you’ll download the “Secure Score Collector” which is essentially some PowerShell scripts and modules. When running the collector, there’s a few points where you’re questioned as to whether some activities are “weird or illicit”. While the scripts are running, you can see how early in the development the tool is, the output is a bit ugly and the logs include some interesting statements like “Cool, looks like everything is square”. Some of the mailbox checks seem like they would take a significant amount of time in a large environment, I’d be curious to see how this portion of the tool scales.

My tenant scored a 301 out of 492:

Once the data collection is completed, it is uploaded to the Microsoft service for further analysis.

Looking At The Results

The score is presented in a dashboard view and the “Score Viewer” shows multiple runs of the tool for historical purposes.

Each of the criteria evaluated is listed as a “GOOD” or “FIX IT!” result with the latter providing a link to the general area of configuration. I suspect you won’t find that all of the “FIX IT!” items will necessarily be resolved based on your organization’s requirements. As an example, “Let external people access your sites” was flagged as being enabled in my tenant, but I’m aware of it and want it enabled; regardless, it’s nice to see it listed there as a reminder.

Final Thoughts

This feature is certainly in a development stage so I’m sure the collector tool will be polished and the UI will be cleaned up. I do like that Microsoft is putting effort into this type of feature and believe it could become a portion of a larger “health check” for Office 365 tenants in the future. It’ll be interesting to see how this tool evolves, how deep it will be able to go and how well it will be able to keep up with the constant change in Office 365. In the meantime, feel free to check it out, there is an email address on the site for comments or issues that you may find.

Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – What’s Your Office 365 “Secure Score”? was first posted on January 12, 2016 at 10:00 am.

Office 365 – Script To Recreate “Managed Folders” Functionality

$
0
0

Despite all the new features that Microsoft has introduced around Retention Policies and Archiving, some clients that I work with still long for the day of “Managed Folders”.

The “Managed Folders” feature left us with Exchange 2010 and the replacement, “Retention Policies” and “Retention Tags”, can be a difficult to adopt for some organizations.

In many cases, I’m working with clients that were previously allowing users to “archive” emails to PSTs so the users are familiar with a “drag and drop” approach to storing away messages. Tagging individual emails with a “Personal Tag” and leaving it in place can be a training struggle that the organization is not ready to take on.

Below is a script I developed for recreating some of the “Managed Folders” functionality that existed in earlier versions of Exchange.

The Use Case

This is by no means a perfect solution, ideally your organization should embrace Retention Policies and Retention Tags. However, there are times where the textbook “right” solution is not the best fit for an organization and this can get you somewhere in the middle. At a high level, we’re basically talking about automating the creation of a folder in a user’s mailbox and assigning it a Personal Tag that does not delete the folder contents.

Here are a couple of use cases:

“Drag and Drop Archivers”
If your users were previously allowed to use PSTs for “archiving” and you’ve rightly decided to steer away from that, this might be for you. By creating a folder and assigning a Personal Tag, you can give users a place to “drag and drop” emails in a folder protected from your Default Retention Policy tag. So you can have a policy to only keep emails for 3 years but allow users to keep records longer in the protected folder.

Import of Legacy Data
Perhaps you’ve rounded up all those PSTs and have decided to ingest them into you user’s mailbox via Microsoft’s PST Import Service. The online archive mailbox would be a good choice here as that mailbox is not cached by Outlook but if you’re not using archive mailboxes, the data is going into the primary mailbox. Another reason the archive mailbox may not be the best target is if you have Retention Policies in place to delete after a certain period of time. The Retention Policy applies to both the primary mailbox and the online archive mailbox so you wouldn’t want to ingest all the data and then have it purged out based on it’s age. Providing users with a folder for their ingested data that is protected with a Personal Tag allows you to go forward with good practices and apply more strict policies on the imported data in the future.

Some Influences…

Some of the code in this script was inspired by examples from Glen Scales. That should be the standard disclaimer on all things related to EWS as any research in this space seems to lead back to Glen’s site.

Prerequisites

This script uses version 2.2 of the EWS Managed API. If you don’t have it installed, you can download it from Microsoft: Microsoft Exchange Web Services Managed API 2.2. The API should install in a default folder of “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”, if you install it in a different location you will want to modify the script or use the command line parameter to specify the alternate location.

You will also need an account that is setup for Impersonation. If you don’t have an account with this role, you can easily set it up with these instructions: “How To: Configure Impersonation“.

Using The Script

The script takes up to seven command line switches although you can specify as few as three. The parameters are as follows:
TargetMailbox
The SMTP address for the mailbox that you want to populate.

FolderName
Name of the folder to create.

RetentionTag
Name of the personal tag to assign to the folder.

AutoD
If specified as $True, Autodiscover is used to determine the EWS endpoint. Default value is $True.

EwsUri
EWS endpoint for target mailbox. Default value is to use Office 365 if not using Autodiscover.

ApiPath
Location of EWS API. Default path is “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”.

Version
Exchange version to be used by EWS. Default is “Exchange2013_SP1” and likely does not need to be changed unless you’re using an earlier version of Exchange. Acceptable options are documented at “EWS schema versions in Exchange“.

So using the following would create a folder called “Archived Emails” in the mailbox and assign it a Personal Tag labeled “Never Delete”:

.\Create-ManagedFolder.ps1 -TargetMailbox test.user@iwitl.com -FolderName "Archived Emails" -RetentionTag "Never Delete"

When executing the script, you’ll be prompted for the credentials of the account that has the Impersonation role.

User Experience

Your user, or entire organization, now has a folder where they can “drag and drop” emails so they are protected from a Default Policy Tag that may archive or delete items.

Limitations

It should be noted that the user, as the owner of the mailbox, can still manage the folder you create including changing the assigned Personal Tag or even deleting the folder. Also, during creation of the folder, if the folder is found to exist, the script will just log a message to the console and not touch the existing folder.

Download

The script for this post can be found in the Microsoft Script Center at the following link: Create-ManagedFolder.ps1


Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – Script To Recreate “Managed Folders” Functionality was first posted on March 23, 2016 at 9:00 am.

Office 365 – Script to Perform Message Trace By Subject

$
0
0

Just a quick post today on a recent script I had to put together.

The message trace feature within Exchange Online works pretty well but can be a challenge if you want to search based on a particular email subject. In a scenario where you want to know who received an email or a set of emails, you have to employ some tricks to be able to query large amounts of logs.

The script below allows you to search on a subject or variants of a subject going back X number of days. The output is logged to a CSV file showing the details of the trace log entry.

Some Influences…

Some of the code in this script was inspired by the example at “Praveen’s Blog“.

Using The Script

The script takes three command line switches and all are mandatory. The parameters are as follows:

Days
Number of days back to search.

Subject
Subject of message to search.

OutputFile
Name of CSV file to populate with results.

In the scenario where you’re looking for something like a phishing campaign, you might know that the emails all come through with a unique but patterned subject. So you may have subjects like “Invoice TUINV65988 from Tip Top Delivery” and “Invoice HXINV44152 from Tip Top Delivery” where the only difference is the “invoice” number. Using the asterisk in your subject line will allow you to search for variants.

So using the following would search 5 days back for an email with the subject “*Invoice*Tip Top*” and save the results in c:\scripts\output.csv:

.\Get-MessageTraceBySubject.ps1 -Days 5 -Subject "*Invoice*Tip Top*"

During the query, which can take an extended amount of time, you can see in the progress bar what date range is currently being evaluated. Messages are evaluated in batches of 5,000 per query.

Limitations

The Get-MessageTrace cmdlet only returns a maximum of 5,000 results per query unless you use paging and then you can return up to 1,000 pages. So the theoretical limit on this query is 5,000,000 entries.

Download

The script for this post can be found in the Microsoft Script Center at the following link: Get-MessageTraceBySubject.ps1


Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.


Office 365 – Script to Perform Message Trace By Subject was first posted on March 25, 2016 at 10:00 am.

Office 365 – Providing Your Users Visual Cues About Email Safety

$
0
0

It seems like every week I see a new phishing story coming through my social media feeds. The stories are all basically the same, someone with access to financials in an organization receives an email from “an executive” and follows instructions to wire thousands, hundreds of thousands or millions of dollars overseas.

While I’m admittedly surprised that large sums of money are transferred based on emails without any type of validation, it apparently is not uncommon. The email turns out to be, of course, not from an “executive” and the money is in most cases is long gone.

The other attack that seems to be making the news quite a bit these days is the distribution of “ransomware” via email. In particular, it seems like the healthcare industry is targeted with these types of attacks. A user opens an email attachment and suddenly they’ve encrypted whatever files they have access to; short of restoring the data from backups, the only answer is to pay a ransom in Bitcoins.

Proper security includes depth in defense and in some cases your users are the final layer of protection. Below are a few things that can be implemented at virtually no cost that could help protect your organization.

Notable Attacks

If you’re asking “does this really happen”, here are a few recent examples for you:

So now that we’ve established that the threat is real (and costly), how does this happen?

How It Happens

Short of a compromise of your internal systems, there’s basically two ways that these emails trick your users:

Mismatched Senders
To understand this scenario, you need to know that every email has essentially two “from” addresses. You have the “mail from” field which is also referred to as the “envelope” or “P1” address and then you have the “from” field which is referred to as the “P2” address. Many of your spam filtering solutions will look at the P1 address so what happens is the phishing email is sent with a P1 that is from a company that is publishing a valid SPF record but the P2 (which is what the user sees in Outlook) will appear to be from your organization. So the message arrives and to your spam solution it looks legit and to the user it appears as internal. When the user replies to the message, they likely have not noticed that it’s actually going to the P1 address.

Similar Domain Names
In this scenario, effort is made to register a domain similar to your own. So if your domain is “iwitl.com”, the email might come in with the domain “lwitl.com”; assuming the username portion of the email matches, it takes a keen eye to catch this. (Don’t see the difference? The first “I” was replaced with an “L”.) Combined with the above where the P1 was “ceo@lwitl.com” and the P2 (which the user sees) is “ceo@iwitl.com”, it really is asking a lot of users to catch this.

Microsoft Fights Back

Microsoft is implementing a few things to help defend against these types of attacks. One of these features is “Safety Tips” which is a visual indication in OWA around how safe an email is. Unfortunately this feature is only rolling out to OWA today although I wouldn’t be surprised to see it make its way into Outlook in the future. Another feature, related to HTML links and attachments, is “Advanced Threat Protection” which is part of the E5 license or available separately as an add-on.

What You Can Do

First of all, if you don’t have a proper SPF published today, you should start there. After that, implementing DKIM and DMARC can help protect against “insider phishing” emails. Even if you implement DMARC with an action of “none”, you can use a transport rule to protect your own users from “insider phishing” emails. For more details on this setup, see “Office 365 – SPF, DKIM and DMARC in Exchange Online“. Another option is to modify inbound emails and provide “visual cues” to your users about the source of the email.

Providing Visual Cues

I have somewhat mixed feeling on this type of action. I’ve seen it implemented at a few clients and while I’m not a fan of modifying the content of the email, it could prove helpful. The effectiveness will certainly depend on the percentage of external vs internal emails that a person receives; at some point I’m sure there’s a subconscious habit to ignore any warnings.

The idea here is to modify the either the subject line or body of an email such that a user has additional information about it. While messaging admins might look at the message headers, it’s unreasonable to think that your average user is going to think about that. You can easily use transport rules to give users a little more insight as to whether an email is safe or not. In the earlier stated phishing examples, one would hope that it would at least cause the recipient to ask a few more questions before wiring millions of dollars overseas.

As an example, you might force all external email to show the following:

And if a message fails SPF because a company has failed to properly configure it, you might modify the email as such:

Configuration

The setup here is not that difficult. Basically it’s two transport rules that use the “prepend disclaimer” function to modify inbound emails. If you have emails that are known to be spoofed (e.g. external applications) then you may need to add some exceptions.

Rule for External Senders
You’ll want this rule to be a higher priority than the others (basically just for formatting purposes). It can be created with the following code:

New-TransportRule -Name "Visual Cue - External to Organization" -Priority 0`
-FromScope "NotInOrganization"`
-ApplyHtmlDisclaimerLocation "Prepend"`
-ApplyHtmlDisclaimerText "<div style=""background-color:#FFEB9C; width:100%; border-style: solid; border-color:#9C6500; border-width:1pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;""><span style=""color:#9C6500; font-weight:bold;"">CAUTION:</span> This email originated from outside of the organization.  Do not click links or open attachments unless you recognize the sender and know the content is safe.</div><br>"

As a reminder, you may need to add exceptions to this rule for addresses that are technically external but you don’t want to be tagged as such.

Rule for Invalid SPF
For this rule, we’re looking for all scenarios where the SPF evaluation returns anything other than “Pass”.

New-TransportRule -Name "Visual Cue - No SPF Validation" -Priority 1`
-HeaderContainsMessageHeader "Authentication-Results"`
-HeaderContainsWords "spf=TempError","spf=PermError","spf=None","spf=Neutral","spf=SoftFail","spf=Fail"`
-ApplyHtmlDisclaimerLocation "Prepend"`
-ApplyHtmlDisclaimerText "
WARNING: The sender of this email could not be validated and may not match the person in the ""From"" field.
"

Limitations

Again, this is not a perfect solution and Microsoft is likely to eventually bring features like “Safety Tips” to Outlook and the mobile platform. If the email is sent as “plain text”, the appended warnings lose some of their visibility as the warning is also in plain text without any color.

Additionally, the scenario I really wish we could account for here is when the message is sent with a similar domain and the P1 and P2 don’t match. Unfortunately, there is not an X-header that indicates this even though it seems like it would be relatively easy to identify. Also, if an email is received with a similar domain where the P1 and P2 do match, it’s going to be difficult to catch. With both of these scenarios, you can only hope that the notification of it being an “external email” is enough.

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.


Office 365 – Providing Your Users Visual Cues About Email Safety was first posted on April 4, 2016 at 10:00 am.

Office 365 – The (Previously) Undocumented AAD Connect Filter

$
0
0

Just a quick post today on something that doesn’t seem to be well documented and could be helpful…

AAD Connect is basically Microsoft’s third version of their Directory Synchronization tool for Office 365. While AAD Connect includes more of a “wizard-type” interface for configuration of components such as AD FS, it’s also the current Directory Sync tool.

With each iteration of the Directory Sync tool has come changes; the method of forcing a sync has changed in each version and in the latest version of AAD Connect, we have a new set of default filters.

Below is a summary of the default AAD Connect filters along with two somewhat undocumented filters that could be used to your advantage.

How To See The Filters

You can see the filters by launching the “Synchronization Rules Editor” (“C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe”). At a high-level, you should understand that are basically two types of rules: “Inbound” and “Outbound”. The rules dictate the attribute flow in relation to the AAD Connect metaverse; so “Inbound” rules cover data going into the metaverse and “Outbound” rules cover data coming out of the metaverse.

Default Filters

Most of the default rules are pretty well documented on this page: Azure AD Connect sync: Understanding the default configuration.

As a summary, the default rules will not sync users…

  • without a source anchor
  • without sAMAccountName populated
  • with the sAMAccountName of “SUPPORT_388945a0”
  • with a mailNickname that begins with “SystemMailbox{”
  • with a sAMAccountName that begins with “AAD_”
  • with a mailNickname that begins with “CAS_” and contains “}”
  • with a sAMAAccountName that begins with “MSOL_”

The rules will also not sync:

  • Mail-enabled Public Folders
  • System Attendant Mailboxes
  • System Mailboxes
  • Discovery Mailboxes
  • Exchange Role Groups
  • Conflict Objects (DN begins with “\\0ACNF:”)
  • Dynamic Distribution Groups

The Not-So-Documented Filters

If you’ve used the “Synchronization Rules Editor” to peek at the default rules, you’ll see there are two filters that can be helpful when needing to exclude adhoc objects.

The inbound rules for users and groups both contain a filter that use the “adminDescription” attribute. If a user has this attribute populated with a value that begins with “User_” or a group has the attribute populated with “Group_”, it will not be synced into the metaverse.

So if you have objects that you don’t want to sync that are buried within an OU in your sync scope, you can use this attribute to filter out these individual objects. Populating the “adminDescription” attribute with the value “User_NoO365Sync” or “Group_NoO365Sync” (depending on the object type) will allow you to easily filter these objects.

There are a couple advantages of using “adminDescription” over a custom filter that sets “cloudFiltered” to “True”. First of all, the filter is already there in the base set so there’s no additional configuration needed in AAD Connect. The second advantage is the object is not pulled into the metaverse like it is with “cloudFiltered”. You’ll occasionally encounter scenarios where you need to purge an object from the metaverse to resolve the issue and just setting “cloudFiltered” will not do this for you.
 
Did you find this article helpful?

Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.

Looking to do some more reading on Office 365?

Catch up on my past articles here: Joe Palarchio.



Office 365 – The (Previously) Undocumented AAD Connect Filter was first posted on April 11, 2016 at 9:00 am.

Office 365 – Speculation on New Exchange Online Functionality

$
0
0

While the Office 365 Roadmap is the authoritative source for features being added to the service, many features seem to receive a sort of “official announcement” via blog post or otherwise before they appear on the roadmap.

Before the feature announcement, one would assume that Microsoft has made a fair amount of progress of integrating components of the new feature into the service. Occasionally, some of these components become visible long before public announcement of the feature.

A bit of a different type of blog post today, one based on pure speculation resulting from a few recent observations.

Could these be signs of future functionality to come?

Undocumented Cmdlets

Through some keyboard fumbling, I recently stumbled across these two cmdlets:

  • Get-MailboxLocation
  • Get-MailboxPreferredLocation

The cmdlets quickly caught my attention as I had recently put together a script called “Get-MailboxLocations.ps1” that provides feedback on the various datacenters where your mailboxes are stored. Neither of these cmdlets seem to have any public documentation.

Get-MailboxLocation

This command returns a couple interesting attributes: “IsMigratedConsumerMailbox” and “IsPremiumConsumerMailbox“.


There’s also a “SiloName” attribute which I honestly have no clue about.

Speculation

These attributes lead me to believe they’re related to the recently announced “Outlook Premium” pilot and potentially a merging of the “Outlook.com” consumer service with Office 365. They certainly seem to indicate that Office 365 will be hosting “consumer” mailboxes in the future.

Get-MailboxPreferredLocation

There has been a long-standing request from international organizations to have “geo-tenants” or tenants where data can be distributed globally as opposed to being restricted to a single region. While I haven’t read anything “official”, I suspect we’ll eventually have that functionality in one form or another.

Looking at the attributes, “Get-MailboxPreferredLocation” provides a few interesting values:


Based on a cursory check of a few mailboxes, the “MailboxPreferredLocation” seems to reference the region from which the mailbox owner is accessing the mailbox. For my test mailbox, this is “NamNorth” which is the same as what I resolve “outlook.office365.com” to.

The “MailboxAlternatePreferences” seems to list out the various datacenter locations that I noted in my “Get-MailboxLocations.ps1” script. This list of datacenter codes seems to include 9 more entries than other lists that I’ve seen so it may represent new capacity (Canada?) or locations I just have not come across previously.

Speculation

These attributes could be for a couple things: Microsoft could be looking to optimize the traffic on their network by placing the mailbox in the location closest to the point from which the user accesses it. In addition to creating better user performance (although possibly unnoticed), it would in theory reduce traffic between datacenters. For the list of datacenters, is the list potentially a lead into “geo-tenants” where your data could be spread across a list of regions?

What Do You Think?

Let me know what you think about the above in the comments and what your thoughts are about what they might be for.

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.


Office 365 – Speculation on New Exchange Online Functionality was first posted on April 19, 2016 at 11:30 am.
Viewing all 67 articles
Browse latest View live