O365 EOP Phishing Rule

I had a client last week that was constantly complaining about receiving a lot of phishing emails. I had done everything I could think of in order to try and mitigate them in Exchange Online Protection (EOP) and finally broke down and opened up a support case. Upon submitting the numerous examples to the support engineer he guided me through implementing an undocumented change to the phishing threshold via a header manipulation.

We created a mail flow rule that stated if the sender is outside of the organization and the recipient is the client's domain, then add a message header "MS-Exchange-Organization-PhishThresholdLevel" and set the value to 2 (the default is 4):

Ever since implementing this the client has said they are no longer receiving any phishing emails.

Exchange Hybrid Mailbox Move Fail - 401 Unauthorized

This summary is not available. Please click here to view the post.

Skype for Business Hybrid Remote PowerShell

I recently began to start working on a couple hybrid deployments both internally and for clients. One of the first things that noticed was it was not as straight forward to get connected to remote PowerShell as it was for Azure AD or Exchange Online. The first thing to note is that if you are in a hybrid and you have your lyncdiscover.domain.com pointed to your on-premise environment you will be greeted with the following error:

Get-CsPowerShellEndpoint : Unable to connect to the remote server

At C:\Program Files\Common Files\Skype for Business

Online\Modules\SkypeOnlineConnector\SkypeOnlineConnectorStartup.psm1:94 char:26

+             $targetUri = Get-CsPowerShellEndpoint -TargetDomain $adminDomain

+                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Get-CsPowerShellEndpoint], WebException

    + FullyQualifiedErrorId : System.Net.WebException,Microsoft.Rtc.Management.OnlineConnector.GetPowerShellEndpointCm

   Dlet

Normally the workaround that has been in place for this is to specify the -OverrideAdminDomain switch and specify your tenant. However I have recently learned that this does not always work. When I tried I was greated with the following error:

New-PSSession : [admin0b.online.lync.com] Processing data from remote server admin0b.online.lync.com failed with the

following error message: The specified tenant 'spscom.onmicrosoft.com' could not be found in current forest. Please

verify the tenant Identity and then try again. For more information, see the about_Remote_Troubleshooting Help topic.

At C:\Program Files\Common Files\Skype for Business

Online\Modules\SkypeOnlineConnector\SkypeOnlineConnectorStartup.psm1:118 char:16

+     $session = New-PSSession -ConnectionUri $ConnectionUri.Uri -Credential $webt ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin

   gTransportException

    + FullyQualifiedErrorId : IncorrectProtocolVersion,PSSessionOpenFailed

I opened a ticket with Microsoft and we were able to get connectivity to work by specifying the -OverridePowerShellURI parameter, and then using the same URL that you access the control panel within O365:

New-CsOnlineSession –Credential $cred –OverridePowershellURI –OverridePowershellURI https://admin2a.online.lync.com/OcsPowershellLiveid”

We escalated this issue to the product group in which responded with the following:

There is a known issue currently where DomainUrlMap (what gets used for Autodiscovery) is only being populated with the domains of online enabled users. While our tenant does have some online enabled users, it would appear that those users are all on spscom.com – Autodiscover doesn’t know about the spscom.onmicrosoft.com domain so you get routed somewhat randomly when trying to resolve that domain.

There are two workarounds – 1) you could enable a user for spscom.onmicrosoft.com and subsequently disable it, once the domain is in the DomainUrlMap it should remain there, or 2) use “-OverrideAdminDomain spscom.com”, which is already in the DomainUrlMap.

Solution:

I created a new cloud only user with an onmicrosoft.com UPN, licensed them for Skype for Business Online, and then was able to sucessfully access remote PowerShell:

You can then remove the cloud only user it is only needed to add the onmicrosoft.com domain to the DomainUrlMap

Federating Lync 2010 Hybrid with Skype for Business Online

I had an interesting case today where a client who was running a Lync 2010 hybrid with O365 Skype for Business online reported that federated partners who were also using Skype for Business Online could not IM, call, screen share, or see presence.  My initial reaction was to check and see if they had configured their on-premises instance for federated domains to use the “sipfed.online.lync.com” proxy FQDN as both Phil Sharp  and our Tom Pacyk had blogged about issues with Lync 2013 when you have the domain configured as both an Edge Server and Hosted Provider. Sure enough they had a couple domains configured this way.  I used the following command to update all the domains to not specify sipfed.online.lync.com as a proxy fqdn:

Get-CsAllowedDomain | Where {$_.ProxyFqdn -eq "sipfed.online.lync.com"} | Set-CsAllowedDomain -ProxyFqdn $null

I forced replication and waited 15 minutes and re-tested, still no luck. I then pulled the client logs and noticed that my messages were resulting in a 504 Server Time-Out:

The entire message did not give me much to go on:

Server: IncomingFederation/6.0.0.0
ms-diagnostics: 1036;reason="Previous hop shared address space peer did not report diagnostic information";Domain="clientpartnerdomain.org";PeerServer="sipfed.online.lync.com";source="sip-na.clientdomain.com"
ms-edge-proxy-message-trust: ms-source-type=AuthorizedServer;ms-ep-fqdn=na1.clientdomain.com;ms-source-network=federation;ms-source-verified-user=verified

I then decided to collect SIP and S4 traces from the edge server while attempting to IM a user on S4B online, the trace at this point also did not provide much information other than that it was being routed correctly but that once it reached O365 it would just timeout:

At this point I felt that this had to be something with O365’s Skype for Business settings and not an issue with our client’s on premises configuration. So I checked the portal’s settings and they had configured “On only for allowed domains” and enabled “Let people use Skype for Business to communicate with Skype users outside your organization”.

So federation was enabled, however it was only for specific domains, so I added the clientpartnerdomain.org to the list of allowed domains (which was empty) and then waited 30 minutes and sure enough it worked!

SOLUTION:

Make sure that if you have a hybrid configuration that your on premises allowed domains, are also listed in your O365 tenant! 

Script: Office 365 Bulk Licensing

Recently I was asked to look into migrating some on-premise Exchange 2010 archives to Office 365.

In order to do so you must first license each user on Office 365 in order to migrate their archive. I had a fairly large number of users to license in Office 365 so I thought that there was bound to be a script out there to accomplish this. My searches took me to Roman Zarka’s blog however his script would not work if the user was not licensed. So I modified his script to ​check if the user was or was not licensed and then either license them or modify their current license.

The script assumes that you have already installed the Office 365 PowerShell Cmdlets as well as the Sign-In assistant.

Download O365BulkLicensing.ps1

References:

http://blogs.technet.com/b/zarkatech/archive/2012/12/05/bulk-enable-office-365-license-option.aspx 

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh124998.aspx