The free Skype for Business basic client was released this week
The comparison table of features is found at https://technet.microsoft.com/en-gb/library/dn933896.aspx
The free Skype for Business basic client was released this week
The comparison table of features is found at https://technet.microsoft.com/en-gb/library/dn933896.aspx
In a previous post I talked about the admin tasks required in setting up Mobile Device Management in Office 365, in this post I look at the end user experience on Android.
During this testing I’m using an Android device running version 5.1.1 and I’m using Microsoft’s Outlook App rather than the built in mail client.
Upon opening the app for the first time I’m presented with the usual login box
Because I’ve already turned on MFA on my account I get prompted to authorise the app (I strongly encourage everyone to have Multi-Factor Authentication turned on wherever it is available)
Once authenticated I’m prompted to Enrol my device before I can continue
After clicking Enrol my browser opens and I’m told I need the Intune app, which is available from the Play store
The app is a small download
It needs access to the device and lists its requirements as:
After installation and opening the app we’re presented with another Sign In prompt.
After signing in we get the option to enrol the device, it’s still not too late!
One last confirmation of what we are going to allow it to do.
Now the device goes through the enrollment process
We’re prompted to name the certificate that’s installed, I chose to leave mine the default
We’re then greeted with the Intune application page
On the My Devices tab we can see the enrolled device
To check the details and compliance information you can click on the system generated device name to bring it up
You can change the device name by clicking on the pencil icon to make it something more recognisable.
From an admin perspective we can now see the device in the portal and are able to wipe if need be.
Managing mobile devices and securing your endpoints is an important task, there are many MDM solutions out there, including Microsoft’s own InTune. But what if you’re a small company? Well if you’re using Office 365 then you can take advantage of the Mobile Device Management for Office 365 feature to provide basic MDM features such as ensuring devices connecting aren’t Jailbroken, have a device password set and allow remote wipe.
In this post I’ll walk through the administrative steps required to get the tenant ready for MDM and how to apply it to users
So, we browse to the Mobile Management section within the Office 365 portal and we are greeted with:
After clicking Let’s get started and once the Microsoft automation tasks have completed and MDM is ready we are greeted with:
First thing is to complete the settings and remove the error
To configure the tenant domain(s) you need to add two new cname records as per http://go.microsoft.com/fwlink/p/?linkId=525583
Now, if you’re not going to have Apple devices then you can, as it says skip that configuration.
After clicking on Set up, we have to download the CSR from our account
Next we have to browse to the Apple Portal
Sign in with an Apple Account (ensuring it’s an account that isn’t tied to a specific user so can continue to be used as the certificates will need renewing)
Click on Create a Certificate
Use the Choose File button to browse and select the CSR file generated earlier.
Once processed use the download button to download the PEM response file
You can close out the Apple website and upload the PEM file.
Now we have a nice green tick to say we’re set up
Now we need to create polices that can be applied to users, the first step of which is to ensure we have a group in Office 365 that we can apply the policy to
After ensuring our groups are created we can create our Device Management policies.
We give the policy a name
Now you can choose the policy options
Then some additional options
Next, we have the option to just save the policy, but doing so will not apply it or we can apply the policy straight away
Now we can browse to the group(s) we created earlier and add them
Once the group(s) are added we can continue
We are given a summary of the policy
Back in the portal we can see that the policy has been created and that it is being turned on
After a little while we can see that its status has been set to on
Now it is just a case of assigning users to the group and they will get the policy assigned. I hope to cover the client experience in another post
I often access my Exchange Online mailbox via my browser when working from home rather than firing up the Outlook client on the work laptop and recently had cause to add an appointment that was in an ICS file to my calendar.
Now this didn’t used to be possible via OWA but I’ve discovered it now is, by going New > Add calendar > from file:
then browsing to the file in question
and then clicking on save, and low and behold, the appointments in my calendar, no full fat client required!
Not sure how long the feature has been there for but I’m glad it has been added.
I was investigating an issue with a customer’s deployment where their on-premise Exchange users couldn’t see the free/busy information of the pilot users in Office 365.
After looking through the logs on all of their servers I found event id 4002 on one of them:
So, the EWS request was being blocked by an authenticating proxy, in their case TMG.
After a little investigation on the TMG it was identified that their default web filtering policy was restricted to Authenticated Users and as this request was coming as the Exchange server account itself it was being denied.
Now, they already had a policy in place on the TMG with a set of addresses that could by-pass the authentication and go straight out, so simply adding *.office365.com to this list allowed Exchange to connect to the EWS of Office 365 and get the free/busy information.
Clients were now working as expected and all should have been good, however the Exchange servers should have had direct internet access and shouldn’t have been trying to go through the proxy in the first place. The customer wanted to know why, so I had to get it to work without entering the url in the by-pass list.
I tried disabling the proxy options within my Internet Explorer settings on the Exchange servers and confirmed I was able to get out onto the internet without going through the proxy. Now, why wasn’t the Exchange server itself able to do this?
I set about trying to work out how to run Internet Explorer as the system account, but how do to do this? Well the answer was to use psexec from the sysinternal tools (available from: https://technet.microsoft.com/en-us/sysinternals/bb545027)
I started on the server that had generated the error, the command I needed was:
psexec.exe -is "c:\program files\internet explorer\iexplore.exe"
the switch -is set the program to run as the system and in interactive mode (without the i you’d not see the browser window as I found on first attempt)
Upon opening the Internet Settings in the newly viewable browser window I discovered that there were proxy settings enabled. Disabling these options allowed free/busy to work, interesting!
I ran the same test on the other Exchange servers but none of them had proxy information entered. Strange.
Until I came across: http://blogs.msdn.com/b/askie/archive/2013/05/09/user-proxy-settings-showing-up-in-local-system-account-correct-way-to-apply-proxy-settings.aspx which talked about how Group Policy settings, if not correctly configured could result in what I was seeing.
So I had a check, all Exchange servers had the same policy applied specifying the Internet Explorer proxy options but it was set to “Authenticated users” only, which shouldn’t include the service and system accounts that Exchange was running under.
But on the server that was reporting this error I did find proxy information located in the registry key: HKEY_USERS\.DEFAULT. \Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections and after I replaced this with the blank key from another server everything worked and Exchange was no longer going through the proxy.
Not having access to their GPO I wasn’t able to confirm its configuration but I suspect it was changed at some point but the server in question had already applied the incorrect settings which are not superseded by the correct configuration.
So the lesson here is, check GPO and the registry for proxy settings and ensure that Exchange servers (and clients) do not go through a proxy when trying to reach Office 365 services and if they must, ensure that it does not require authentication for the Office 365 addresses.
Microsoft does call this out on their Office 365 URL and IP address webpage – https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2
Having recently been troubleshooting a customers hybrid Exchange environment I thought I’d write about my experience.
The customer had an Exchange 2010 deployment and the Hybrid Configuration Wizard had already been run but they were having mail flow problems from their On-Prem to Online mailboxes.
First I decided to perform the basic SMTP connectivity test to Exchange Online Protection to make sure their address was allowed to send mail through. To do this from a command prompt I ran:
telnet [tenantname].mail.protection.outlook.com 25 ehlo mail from: email@example.com rcpt to: firstname.lastname@example.org
Now, normally you should get a “250 2.1.5 Recipient OK” message back however we received:
Our IP address is blacklisted, opps! So we proceeded to resolve the blacklist issue, upon investigation I discovered that the Exchange servers were actually connecting externally as the default IP address on their internet connection, which client devices also used.
I always recommend that mail servers should be presented externally via an IP address that isn’t used by other services just to prevent issues like this.
Once removed from the blacklist we were able to perform the test again successfully, all good, or so we thought!
Email was still not flowing and building up in the queue, at this point I turned on verbose logging on the outbound SMTP connector and went to check the SmtpSend folder for the logs.
Upon opening the logs I found the following, repeated
#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context 2015-09-29T00:08:44.653Z,Outbound to Office 365,08D2B5B9B93409D6,0,,22.214.171.124:25,*,,attempting to connect 2015-09-29T00:08:44.653Z,Outbound to Office 365,08D2B5B9B93409D6,1,[INTERNAL IP]:14101,126.96.36.199:25,+,, 2015-09-29T00:08:44.669Z,Outbound to Office 365,08D2B5B9B93409D6,2,[INTERNAL IP]:14101,188.8.131.52:25,<,"220 AM1FFO11OLC001.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 29 Sep 2015 00:08:43 +0000", 2015-09-29T00:08:44.669Z,Outbound to Office 365,08D2B5B9B93409D6,3,[INTERNAL IP]:14101,184.108.40.206:25,>,EHLO [HOSTNAME], 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,4,[INTERNAL IP]:14101,220.127.116.11:25,<,250-AM1FFO11OLC001.mail.protection.outlook.com Hello [IP ADDRESS], 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,5,[INTERNAL IP]:14101,18.104.22.168:25,<,250-SIZE 157286400, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,6,[INTERNAL IP]:14101,22.214.171.124:25,<,250-PIPELINING, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,7,[INTERNAL IP]:14101,126.96.36.199:25,<,250-DSN, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,8,[INTERNAL IP]:14101,188.8.131.52:25,<,250-ENHANCEDSTATUSCODES, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,9,[INTERNAL IP]:14101,184.108.40.206:25,<,250-STARTTLS, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,10,[INTERNAL IP]:14101,220.127.116.11:25,<,250-8BITMIME, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,11,[INTERNAL IP]:14101,18.104.22.168:25,<,250-BINARYMIME, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,12,[INTERNAL IP]:14101,22.214.171.124:25,<,250 CHUNKING, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,13,[INTERNAL IP]:14101,126.96.36.199:25,>,STARTTLS, 2015-09-29T00:08:44.685Z,Outbound to Office 365,08D2B5B9B93409D6,14,[INTERNAL IP]:14101,188.8.131.52:25,-,,Remote
Now, I like to play spot the difference with logs from working deployments to try and spot things that are not working or incorrect, so I got a log from a working deployment:
2015-04-11T16:24:07.627Z,Outbound to Office 365,08D21A598CD8BB94,0,,184.108.40.206:25,*,,attempting to connect 2015-04-11T16:24:07.643Z,Outbound to Office 365,08D21A598CD8BB94,1,[INTERNAL IP]:30731,220.127.116.11:25,+,, 2015-04-11T16:24:07.659Z,Outbound to Office 365,08D21A598CD8BB94,2,[INTERNAL IP]:30731,18.104.22.168:25,<,"220 AM1FFO11FD013.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Sat, 11 Apr 2015 16:25:42 +0000", 2015-04-11T16:24:07.659Z,Outbound to Office 365,08D21A598CD8BB94,3,[INTERNAL IP]:30731,22.214.171.124:25,>,EHLO mail.[DOMAIN].com, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,4,[INTERNAL IP]:30731,126.96.36.199:25,<,250-AM1FFO11FD013.mail.protection.outlook.com Hello [IP ADDRESS], 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,5,[INTERNAL IP]:30731,188.8.131.52:25,<,250-SIZE 157286400, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,6,[INTERNAL IP]:30731,184.108.40.206:25,<,250-PIPELINING, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,7,[INTERNAL IP]:30731,220.127.116.11:25,<,250-DSN, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,8,[INTERNAL IP]:30731,18.104.22.168:25,<,250-ENHANCEDSTATUSCODES, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,9,[INTERNAL IP]:30731,22.214.171.124:25,<,250-STARTTLS, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,10,[INTERNAL IP]:30731,126.96.36.199:25,<,250-8BITMIME, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,11,[INTERNAL IP]:30731,188.8.131.52:25,<,250-BINARYMIME, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,12,[INTERNAL IP]:30731,184.108.40.206:25,<,250 CHUNKING, 2015-04-11T16:24:07.690Z,Outbound to Office 365,08D21A598CD8BB94,13,[INTERNAL IP]:30731,220.127.116.11:25,>,STARTTLS, 2015-04-11T16:24:07.706Z,Outbound to Office 365,08D21A598CD8BB94,14,[INTERNAL IP]:30731,18.104.22.168:25,<,220 2.0.0 SMTP server ready, 2015-04-11T16:24:07.706Z,Outbound to Office 365,08D21A598CD8BB94,15,[INTERNAL IP]:30731,22.214.171.124:25,*,,Sending certificate 2015-04-11T16:24:07.706Z,Outbound to Office 365,08D21A598CD8BB94,16,[INTERNAL IP]:30731,126.96.36.199:25,*,"CN=mail.[DOMAIN].com, OU=PositiveSSL Multi-Domain, OU=Domain Control Validated",Certificate subject 2015-04-11T16:24:07.706Z,Outbound to Office 365,08D21A598CD8BB94,17,[INTERNAL IP]:30731,188.8.131.52:25,*,"CN=COMODO RSA Domain Validation Secure Server CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB",Certificate issuer name 2015-04-11T16:24:07.706Z,Outbound to Office 365,08D21A598CD8BB94,18,[INTERNAL IP]:30731,184.108.40.206:25,*,[CERTIFICATE SERIAL NUMBER],Certificate serial number
As you can see, after the STARTTLS we should see the “220 2.0.0 SMTP server ready” response followed by the establishment of the TLS connection, but in our case we weren’t and presumably the “Remote” entry was to say it had timed out.
Now I had to find a way to manually establish a TLS SMTP connection, I’m not aware of a way of using the standard telnet based approach to do this so had to find an alternative.
That alternative was to use openSSL to establish the connection, to do this you can use the following command:
openssl s_client -starttls smtp -crlf -connect [tenantname].mail.protection.outlook.com:25
When run work a working machine the connection should establish and look similar to the below (full output is much longer):
However from the customers Exchange server it would not connect
The customer raised it with their firewall team who advised that there was some “app awareness configured and it only allowed smtp over tls” not sure how it worked from a telnet client or what they changed to resolve it but that’s the dark art of firewall appliances!
Securing access to authentication provided through ADFS is important and whilst Microsoft’s Azure MFA services will integrate perfectly with it many organisations choose to use utilise their existing MFA solution of which there are a number supported by Microsoft – https://technet.microsoft.com/en-us/library/dn758113.aspx plus others that aren’t certified.
I’ve performed a few installations now using 3rd party MFA solutions and just wanted to briefly write about an issue I’ve had with using two different solutions.
During the installation of the agent on the first (primary) ADFS server I carefully followed the instructions from the supplier and the agent would install and present the MFA login screen correctly but when it came to installing the agent on additional servers in the same farm I encountered errors with the MFA option not loading.
Neither instruction set from the suppliers made mention of what should be done on additional servers in a farm so I was left with a little trial and error to discover a workaround.
The procedure I’ve found that worked for me (and there may be alternatives or exceptions to this) was to:
1) Install the MFA agent on Primary ADFS server
2) Disable the agent (usally through the agent software) or through the AD FS Management console
3) Move the Primary ADFS role onto the second server (plus update all the others to secondary)
4) Install the MFA agent
5) Repeat steps 2-4 for any additional servers in the farm
After doing this the MFA process worked for traffic going to all the servers in the farm, I’m not sure why the documentation didn’t account for multiple ADFS servers in the farm as after all I’d like to think that running two ADFS servers in a farm should be the most common scenario to provide HA capabilities.
Hope it helps.