In a previous blog post, I wrote about the value of the new Office 365 “Groups.” These are a next generation type of group that replaces the function of a traditional distribution group, and includes the benefits of a security group, along with many other rich collaboration experiences. For example, they offer a shared calendar, shared files via OneDrive, shared OneNote, and a group chat experience in OWA. You can use these groups for Azure AD SSO, and the new March preview of AAD-Connect will dirsync these groups to on-premises.

See: Office 365 “Groups” are next generation distribution lists
and Upgrading Dirsync to Azure Active Directory Connect Public Preview – March 2015 update

I was inspired to write this post after reading my colleague’s post on how to update the primary SMTP address: http://blog.ucparticles.com/2014/11/office-365-groups-how-to-update-primary.html

Basically, when a new “Office 365 Group” is created, it gets stamped with an MyTenant.onmicrosoft.com address, for example: [email protected]

In Keif’s blog post above, he demonstrates how to use Exchange Online remote powershell to update the address to match the vanity domain name, ex: [email protected]. This improves aesthetics and mail routing.

• Obtain a list of existing Office 365 Group mailboxes

  Get-GroupMailbox

• Use the following one-liner to update the primary SMTP address

  Set-GroupMailbox –Identity Name –PrimarySMTPAddress groupname@defaultdomain.com (Insert primary domain here)

Keif also posted a powershell script to read from a CSV file and convert the groups to the new SMTP format. Awesome!

So this solves one part of the conversion, which is to get the groups to use the shorter SMTP domain format.

What about the overall process itself? Let’s say you have 100 distribution groups today and you want to convert them all to Office 365 Groups? How would you go about doing this?

Approach #1 – Create a new O365 Group and then add the existing DL as a ‘member’

Approach #2 – Create a new O365 Group and then delete the old DL. Inform users to start using the new Group.

Approach #3 – Create a new O365 Group, delete the old DL and then update the new O365 Group to use the old DL’s SMTP name, or add it as a secondary proxy alias

There are tradeoffs with each approach, but in general you want to select the approach that prevents NDR’s from occurring, and you want to make sure to automatically subscribe the members of the old DL to the new O365 Group so that they don’t have to manually take any action in order to start receiving new emails from the group. In a future blog post, I will walk through the end to end process.

Update 5/20/2015: If you take approach #3,  I now recommend leaving the primary SMTP address as the onmicrosoft.com address, and adding the old DL as a secondary proxy address. The reason for this is because the new Office 2016 Office Client will not display these Groups if the primary address is not an onmicrosoft.com domain name.

There is a new Azure AD feature that allows you to create O365 groups through the Azure Access Panel. This feature is in Preview (Beta) but this blog post is a walkthrough of this as well as exploring the value of O365 Groups.

You can still create groups in the OWA web Interface as well:

These groups are mighty powerful. Not only can they function as AD security groups (in the Cloud only as they don’t sync down to on-premises (yet), but they also function as email distribution groups and shared calendars. They also provide group chat and file sharing capabilities via a dedicated document library in SharePoint Online. You can also have shared OneNote notebooks with your group! You can also assign Azure AD applications to groups for single sign-on (more on that below).
(Note: for a great whitepaper on these capabilities, click here).

Te

To get started, you have to enable the preview functionality in your Azure AD tenant.

Then scroll down to Group Management and enable the group features

Note: I recommend doing this in your demo environment first so that you can evaluate the functionality before turning it on in production, especially since they are ‘preview’ features.

You will notice that a newly created group from the Access Panel will appear as a “Distribution Group” type.

You can edit the group properties to be able to receive email from outside the organization and you can also subscribe new members so that they are notified when new group conversations occur.

Today Microsoft announced that OneDrive for Business customers will soon have unlimited storage (previous limit was 1TB).

Many people have pointed out that the 20,000 file limit seems to nullify the “unlimited” storage feature.

http://support.microsoft.com/kb/2933738

Due to the current single item limit of 2GB per file, the effective limitation of OneDrive is now 40TB (20,000 * 2GB = 40TB).

Since local laptop hard drives are moving towards low capacity SSDs, I am comfortable with a 40 TB cap being the same as  “virtually unlimited.’

Microsoft increased the consumer version of OneDrive single item limit from 2GB to 10GB. We hope that the business version will eventually support 10GB files too, but we do not have a date on when or if that will happen yet.  https://blog.onedrive.com/onedrive-now-supports-10-gb-files/

Had a strange issue where a user mailbox was created in Office 365 before Dirsync was enabled.

After dirsync was enabled and the domain name was validated, the same primary SMTP alias existed in two places: (1) on-premise where the real mailbox resided and (2) in the cloud where the POC/Pilot mailbox temporarily resided.

The problem that happened was cloud users attempting to email the on-premise mailbox would not get delivered on-premise, because the SMTP address matched against the cloud mailbox.

After removing the license from the cloud user, the mailbox was removed, but the cloud users then got a DSN 5.1.1 NDR undeliverable bounce-back message.

The solution was described in this o365 community forum thread:

http://community.office365.com/en-us/f/613/t/238038.aspx

Essentially it was necessary to remove the msol-user entirely and then let dirsync re-create the mail-user object. Problem solved!

To confirm the symptom was happening, running a get-mailuser in the remote powershell resulted in no results returned whereas it should have had a cloud mailuser even for an on-premise mailbox. This is why the DSN was getting generated.

One work-around that seemed to work was also to set the domain in the cloud to internal-relay instead of the default authoritative but that didn’t seem the cleanest way to solve the problem, even though that seems to be the required configuration during a hybrid migration.  http://support.microsoft.com/kb/2730609

_________________BEGIN Connect.ps1________________________

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection
Import-PSSession $Session -AllowClobber
connect-msolservice -credential $LiveCred
#Remove-PSSession $Session

__________________END Connect.ps1_________________________

The above script connects to two services: (1) Azure Active Directory remote powershell and (2) Exchange Online remote powershell.

This is useful because the former is required to assign and manage licenses to Dirsync’d users in Office 365, and the later is required for managing mailboxes and mailbox moves in Exchange Online.

By combining the two sessions into a single powershell session, it is easier to administer and only have a single powershell window open.

One of the most common misconceptions about mailbox moves to Exchange Online with powershell is that people do not realize that you must run the move in a remote powershell session (see move script below for an example).

One of the most common tasks when getting started with Office 365 is to bulk license users based on a CSV file containing email addresses. The maintenance script below was created to perform multiple actions based on a source CSV file.

___________BEGIN Maintenance.ps1 ___________________

Import-csv c:\users.csv| foreach {

$UPN = $_.email

#The line below is great for testing the CSV file match against Cloud UPN. Helps you understand if your CSV file email addresses are matched up perfectly against cloud UPN addresses.

#get-Msoluser -UserPrincipalName $UPN

#the next line is great for getting unlicensed users. This helps you identify any unlicensed users that need a license applied.

#get-msoluser -UserPrincipalName $UPN | where {$_.IsLicensed -eq $false}

#The line below sets usage location and is required for every user.

#set-msoluser -userprincipalname $UPN -UsageLocation US

#The next two lines assign licenses. In order to get <tenant name> you run this command: get-msolaccountsku (remove the <>)

#$MSOLSKU = “<tenant name>:ENTERPRISEPACK”

#Set-MsolUserLicense -UserPrincipalName $UPN -Addlicenses $MSOLSKU

}

___________END Maintenance.ps1 ___________________

Now that you have licensed your users, it is now time to move mailboxes! (Assumes you have already completed the steps in the Exchange Deployment Assistant for configuring a Hybrid environment).

_______________Move Script.ps1_______________

#When prompted, enter your on-premise AD username and password like Domain\User that is a member of the Exchange Organizational Admins group

#Remember – this script is to be called from within a remote powershell session against Exchange Online, not using your on-premise Exchange Management shell!

$cred = get-credential

Import-csv .\user.csv | foreach {

$UPN = $_.Email

New-MoveRequest -identity $UPN -Remote -RemoteHostname ‘myhybridserver.mydomain.com’ -RemoteCredential $cred -TargetDeliveryDomain ‘mytenantname.mail.onmicrosoft.com’ -BadItemLimit 100 -AcceptLargeDataLoss -LargeItemLimit 100 -SuspendWhenReadyToComplete

}

_______________End Move Script.ps1_______________

Tips and Tricks

1. After you’ve completed the tasks you wanted to perform in the Exchange Online organization, you need to disconnect the session between your local computer and the Exchange Online organization.

Use the following command to disconnect remote PowerShell from the Exchange Online organization.

Remove-PSSession $Session

If you close the remote Windows PowerShell window without following this procedure, the session will have to time out (in approx 15 minutes), and the quota for the maximum number of concurrent connections may prevent you from connecting back to the service on a timely basis (maximum of 3 connections are allowed)

2. If you are setting up a new o365 tenant, and your on-premise AD domain has a default UPN like “myad.local” then you can configure Directory Sync to use an alternate login ID such as the mail attribute so that the email address is mapped to the UPN field in o365. This is beneficial because it saves the effort of changing UPN Id’s on-premise!

http://social.technet.microsoft.com/wiki/contents/articles/24096.using-alternate-login-ids-with-azure-active-directory.aspx

Recent change to Dirsync

It is also important to note that starting with DirSync version 6862.0000 released on June 5 2014 there is no longer a DirSyncConfigShell Console file in the Program Files folder. Instead you just start a normal PowerShell window and run Import-Module DirSync. After that the Start-OnlineCoexistenceSync cmdlet is available.

Common Dirsync Questions

• Even though Dirsync is configured to sync by default once every three hours, you can manually force dirsync to run at any time.
• You can also configure the default interval to run in shorter increments
• The default interval for Dirsync is a completely separate interval than password synchronization. Passwords are synced immediately to Azure AD and the average time before they are effective is usually under 3 minutes.

Recently I was trying to locate guidance for the minimum requirements that an Exchange Hybrid Server would need if the only purpose for the server was to manage on-premise remote mailboxes. An on-premise Hybrid Exchange Server is still beneficial to manage the proxy alias attribute since Directory Synchronization is mostly one direction and therefore you cannot update the proxy aliases for a mailbox in Office 365’s administrative portal. You can use ADSIEdit to manage proxy aliases on-premise, but that is not practical for large organizations wishing to use RBAC.

So I posted this question on the new Office 365 IT Pro Yammer group and got a quick response from an MVP named Steve Goodman:

“An Exchange 2010 Hub Transport server role or Exchange 2013 multi role – with Hybrid keys – will do the trick.
After install you can then manage users, which will show as remote mailboxes (within contacts) in 2010 and Office 365 mailboxes in 2013.
Add a remote domain and other acceptors domains in Exchange and set the remote domain as the Office 365 tenant domain. Set the accepted domains as internal relay. Alter email address policies to suit, as they will take effect as you manage or create users.
If you use a multi-role or CAS server beware the AutoDiscover SCP as it will cause cert warnings. Set it to $null using Set-ClientAccessServer <server> -AutoDiscoverServiceInternalURI:$null
More guidance in [Steve Goodman’s] article here http://searchexchange.techtarget.com/tip/Best-practices-for-managing-Office-365-from-Active-Directory

So I learned that you do not have to run the Hybrid Configuration wizard.

Steve’s blog post does not include the syntax of creating a new remote domain. I used powershell to create the remote domain:

New-RemoteDomain –Name contoso.mail.onmicrosoft.com

Set-RemoteDomain -Identity contoso.mail.onmicrosoft.com -TargetDeliveryDomain $true

Then according to this MSFT Blog, if you want the changes to take effect immediately you have to restart IIS.

Steve points out in his blog that another alternative to ADSIEdit or the Hybrid server for managing the proxy aliases is a PowerShell module written by Andreas Lindhal at 365lab.com.

The only thing I would add to Steve’s guidance is that you may need to convert some of the mailboxes to remote-mailboxes using the enable-remotemailbox command otherwise the local contact object won’t exist in the local AD to manage.

Everyone has heard of Spyware and Malware. Ransomware is becoming an all too familiar term but I feel many IT Organizations assume it is a threat isolated to consumers and not Enterprises. In my opinion, I think most IT Organizations are uneducated about the attack vectors that Ransomware can use to infect an IT Infrastructure.

Case in point, most companies that I interact with do not prevent their IT System Administrators from using Internet Explorer (or other web browsers) from the console of their servers. Only a handful of companies that I have encountered over the years actually restrict outbound TCP connections on the firewall to thwart IT Sys Admins from web browsing on server consoles.

Why is this significant, and how does this behavior relate to the topic of Ransomware? This is the attack vector that most IT Organizations are unaware of. Most of the IT Systems Administrators that I have encountered have justified their behavior of using a web browser on a server by stating that they are smart enough to only browse “Safe” websites to download hotfixes, patches, or search for error messages on IT forums. It is that false assumption that can allow Ransomware to infect an Enterprise. I will explain below how an Enterprise Application such as Microsoft Exchange Server could be taken down by such behavior.

The alarm needs to be sounded because leading security researchers have proven that the most successful attack vectors are being exploited by hackers who are placing advertisements on legitimate web sites. You could be browsing a completely legitimate and “Trusted” web site, but because of an advertisement that contains malicious code, your web browser is now the attack vector that downloads an attack payload into your Infrastructure! Today on June 10th 2014, Microsoft released hotfixes for 59 vulnerabilities in Internet Explorer. This shows you that attackers are going after the web browser to target the enterprise! Hackers are smart enough to not hit an Enterprise head on by attacking the firewall. Instead they target the weak points in the infrastructure, namely the end user who is browsing legitimate web sites. Some of these vulnerabilities are “zero day”, meaning that attackers have discovered the vulnerability before the good guys and no patch is available to fix the problem. These types of lurking vulnerabilities can lay dormant on a web server for weeks or months before being discovered.

Now, imagine if one of your Domain Administrators browsed a legitimate web site which contained an advertisement placed by a hacker?  It is safe to assume that any server that Domain Admin had access could now be “owned” by Ransomware, because most of the recent advanced persistent threats (APT’s) spread by multiple attack vectors once they infect just a single host.  Once ransomware lands on a host, the only way to unlock the data is to pay the ransom! When searching for products to remove the ransomware, use caution, because most of these so called cures are actually viruses that masquerade as ransomware removal tools!

I think most readers would agree with me that we are now talking about a very real scenario, because we are talking about legitimate websites that have been compromised with advertisements. IT Sys Admins that use privileged accounts and perform web browsing to search for solutions to error messages (a common IT Sysadmin task) are the most at risk.  They are exposed when browsing to download patches or drivers onto a server from the internet, because it is more convenient for them than copying it over the network from their workstation.

I highly recommend reading this Cyber Heist newsletter (not from your server console, and not while logged in with your Domain Administrator account!). In this newsletter, the author describes the latest advances in ransomware and I promise it will open your eyes to just how bad things have gotten! I don’t blame you if you were too paranoid to click on the link after reading this blog. =)

The threat to Enterprise Applications: Case Study: Microsoft Exchange

The Microsoft Exchange “Preferred Architecture” was published by Microsoft on April 21st 2014 and recommends against traditional backups. I think you know where this is going if you read the Cyber Heist Newsletter referenced above.

“With all of these technologies in play, traditional backups are unnecessary; as a result, the PA leverages Exchange Native Data Protection.”

Gulp.

The limitation of Exchange Native Data Protection (mailbox replication) is that all copies of the mailbox data are accessible from the Layer3 IP network (a requirement for replication to work). The doomsday scenario is a worm or skilled hacker could destroy or “ransom” all copies of the data. This would leave an organization with 100% data loss. Not only is Office 365 susceptible to this threat, but all customers who follow Microsoft’s preferred architecture.

Therefore, Exchange Administrators should carefully consider the risk of a worm or hacker before completely eliminating traditional backups. All other layers in your defense in depth security apparatus better be air tight! For example, you would have less risk if you deploy a whitelisting solutions from Bit9 Lumension, or Microsoft Applocker. However, it’s nearly impossible to eliminate all risk because according to McAfee Phishing Quiz, 65 percent of respondents can’t properly identify email scams. Theoretically, the human responsible for making decisions on what to allow into the whitelist could be tricked into allowing ransomware to be trusted.

Prevention

1. To reduce the risk of ransomware spreading to servers, prevent IT Administrators from being able to browse web pages while logged onto a server. If servers are located in a separate IP subnet, create an ACL to block outbound 80 and 443 requests from the server subnet. The caveat is you could potentially break applications that rely on external connections to the internet. Therefore you could enable the ACL with logging mode enabled so you could then create a whitelist of allowed sites and then block everything else. The downside is this will increase the administrative burden of the firewall administrator to maintain the ACL. However, the alternative of permitting an IT Administrator to browse websites while logged onto servers is to accept the risk of of infecting the entire Server farm with a worm, virus or Ransomware.
2. Create an IT Policy for Administrators to sign where they will not browse the internet using privileged accounts such as Domain Admin credentials on any workstation. Consider deploying a proxy server that uses Radius or Windows Authentication, and only allow a global group that does not contain these admin accounts.
3. Research commercially available whitelisting solutions (ex: Bit9 Lumension, or Microsoft Applocker).

This approach would not prevent all worms, ransomware and hackers from getting onto your servers, because modern advanced persistent threats (APTs) will spread and distribute themselves across multiple attack vectors. For example, just one infected laptop that has IP connectivity to the back-end servers could spread by taking advantage of a vulnerability in an unpatched 3rd party application. Even unpatched security products from the top security vendors have ironically been used to infiltrate a server. Therefore, Kevin Mitnick style security awareness training is also recommended.

Disclaimer: This blog post is for educational use only. Both myself and my employer are not responsible for any actions you take or do not take as a result of reading this blog post.

Today Microsoft announced the generally availability of Office 365 Message Encryption http://blogs.office.com/2014/02/19/office-365-message-encryption-now-rolling-out/

This is the replacement for Exchange Hosted Encryption (EHE).  Customers who are currently using EHE will be upgraded to Office 365 Message Encryption beginning in the first quarter of 2014.

The service promises “Send encrypted email messages to anyone, regardless of the recipient’s email address”

While this is by far the biggest selling point and improvement over RMS, it could also be a slight drawback because the recipient must have an Office 365 organizational ID or a Windows LiveID associated with the email address that you send to. Although not everyone will have a Windows LiveID, you can still send the encrypted email blindly and hope that they will click the link to enroll in a new Live ID account and then subsequently decrypt the email you send them. The enrollment process is pretty quick and straight forward (if you can sign up for an email account then you can figure out the Live ID enrollment process).

In contrast with RMS, the end-user doesn’t have direct control over which messages will be encrypted with a button. It is up to the Office 365 Administrator to enforce a rule that will apply the encryption. With some creativity, an Administrator can allow the user to indirectly control whether a message is encrypted by filtering on a key word. IMHO, this limitation is also a strength because it doesn’t have any client requirements, as all mail clients can immediately benefit from encryption whether it is enforced by an Admin, or permitted by an Admin using an indirect keyword.

“Easily Set up Encryption”

Yes, the setup is very fast and easy for an Office 365 Administrator. Simply create a new rule in the mail flow section of the Exchange Admin Center inside the Office 365 Portal:

Select ‘Apply rights protection to messages’

There are dozens of ways you could apply encryption based on the variety of rules available. +1 for the flexibility here.

Here is an example of applying encryption to a message where the subject line contains ‘’Encrypted” (Perhaps this could be the key word you tell your users to use when they want to encrypt an email).

The next step is where you provide the rule action, ex: Apply Office 365 Message Encryption.

Next you can configure whether you want to enforce the rule immediately or whether you want to test it out first with a policy-tip notification (for OWA or the Outlook clients that support message tips).

The rules are particularly useful for automatically encrypting emails if they contain sensitive information such as a Social Security Number, Credit Card Number or Drivers License Number.

That’s it for the setup! Nice and easy, right? It’s impressive that such an awesome encryption technology is so easy to setup. You could have full blown message encryption in minutes!

Adding custom branding

You can add custom branding by connecting to Exchange Online powershell and using the get-OMEConfiguration and set-OMEConfiguration

So what about the end-user experience?

An email that bears an encrypted message arrives in the recipient’s Inbox with an attached HTML file that lets the recipient to sign-in to view the encrypted message.

When opening the HTML attachment, the user has the option to view the encrypted message. You can see evidence of the custom branding which can help give credibility to the message.

Recipients follow instructions in the message to authenticate by using a Microsoft account or an organizational account. If recipients don’t have either account, they’re directed to create a Microsoft account that will let them sign in to view the encrypted message.

After being authenticated, recipients can view the decrypted message and reply to it with the same style of an encrypted attachment, so the whole back and forth will remain encrypted.

For additional screen shots of the end-user experience, click here:
http://technet.microsoft.com/en-us/library/dn569287.aspx

How much does it cost?

For $2 per user per month you can get a complete solution for internal and external information protection: traditional Rights Management capabilities like Do Not Forward for internal users, plus the new ability to encrypt outbound messages to any recipient. If you already have an Office 365 tenant, you can try it for free by adding a trial license here:

http://office.microsoft.com/en-us/exchange/redir/XT104181503.aspx

The great news is that if you already have an E3 or E4  license, then you get Message Encryption for free!

(Note: The trial enables you to try Information Rights Management capabilities as well as the capabilities of Office 365 Message Encryption)

So do you still need Rights Management if you use Message Encryption? Perhaps… because Windows Azure Rights Management in Office 365 prevents sensitive information from being printed, forwarded, or copied by unauthorized people inside the organization. That is why Message Encryption is labeled a companion service with RMS, not a replacement.

If you are using Exchange 2013 on-premise, you can also benefit from Message Encryption by configuring Hybrid mailflow.

Thank you Microsoft! This is great stuff!!

The official site for Office 365 Message Encryption is here:

http://office.microsoft.com/en-us/exchange/o365-message-encryption-FX104179182.aspx

IT Pro’s can get more technical information about Message Encryption here:

http://technet.microsoft.com/en-us/library/dn569286.aspx

One of the features available during a Hybrid / “rich-coexistence” migration to Office 365 is the friendly URL redirect that users can receive if they try using the old OWA URL that was pointing to the old Exchange server.

However many people may not be aware that using that feature requires establishing a legacy namespace with Exchange 2007, as the Exchange 2013 cannot proxy all workloads for Exchange 2007.

Reference: http://michaelvh.wordpress.com/2012/10/09/exchange-2013-interoperability-with-legacy-exchange-versions/ 

For example, owa.contoso.com would be redirected to the Hybrid server, and then it could proxy the request to a back-end legacy Exchange server.

However, if it is more important to an organization that the impact to mobile phones is reduced, then you can leave the pre-existing namespace (ex: webmail.contoso.com) intact and instead introduce a new external namespace for the Hybrid server (ex: mail.contoso.com) so that it exists side by side with the previous environment.

The benefit is that users only have to change their mobile phone setting once.

The downside with this approach is after a user’s mailbox migration completes, if the user attempts to logon to the old Exchange OWA URL then they will get an error message that their mailbox cannot be found.

This can be mitigated with a communication plan that provides the new OWA URL so that users don’t try to go to the old URL. To me, that’s worth the tradeoff of having to make the user change their mobile device twice: once to legacy.contoso.com and a second time when their mailbox migrates to Office 365.

For example, among the things you can communicate to an end-user prior to their mailbox being migrated:

• You will get a pop-up to restart outlook

• You will be prompted to enter credentials, please use your email address as your username.

• The new URL for Outlook Web Access is http://outlook.com/contoso.com

• Follow these instructions for re-attaching your mobile device to Office 365
http://office.microsoft.com/en-us/office365-suite-help/set-up-and-use-office-365-on-your-phone-or-tablet-HA102818686.aspx