Monday, December 15, 2014

ActiveSync maintenance in O365

I manage a hybrid O365 + On-premises Exchange 2010 environment.  As such, general management is a bit of a pain, as I still have a handful of production users on-prem.  These are mostly contractors, and we kept them on-premises to avoid hitting our O365 license cap.  I like to have a bit of padding there.

Long story short, I need to report on associated ActiveSync devices in our environments. In either case this is fairly simple, but to combine the data I need to correlate info from Exchange 2010 and O365.

Let's start with O365.  The current command is Get-MobileDevice [see also: Get-MobileDeviceStatistics].  This can be piped out via Select and we can get relevant Properties.  Once we get relevant fields down, we will send this to CSV for consumption.

Get-MobileDevice | Select -Property UserDisplayName,DeviceType,DeviceModel,FriendlyName,DeviceOS,DeviceTelephoneNumber,DeviceAccessState,WhenChanged


  • UserDisplayName - Display name of user mailbox owning the Device.
  • DeviceType - Class of Device connection.  iPhones are straightforward, but other manufacturers give any kind of info you could imagine.
  • DeviceModel - Similar to DeviceType, iPhones are clearly enumerated, others not so much.
  • FriendlyName - This is the Device Name as assigned by it's owner.  Typically "so-and-so's iPhone" or similar.
  • DeviceOS - Helpful when running reports to know what device versions are connecting.  
  • DeviceTelephoneNumber - another useful bit of info.
  • DeviceAccessState - Allowed or Blocked, defines whether a given device has been blocked for ActiveSync.
  • WhenChanged - I was hoping for a "last check-in", but this isn't it.  This merely shows when the connection was configured or updated.  A device system update seems to cause the info to change/refresh and changes this value.
This covers the O365/Exchange Online portion.  I piped Export-CSV to the end to deliver a consumable document.

Exchange 2010 is a bit of a different beast.  Since this is the on-premises environment, I'll have fewer entries overall.

Get-ActiveSyncDevice | Select -Property UserDisplayName,DeviceType,DeviceModel,FriendlyName,DeviceOS,DeviceTelephoneNumber,DeviceAccessState,WhenChanged

Note that here, the UserDisplayName returns the full cn from LDAP.  That's not as friendly as it is in 2013/O365.  Otherwise, the dataset matches well.

Tuesday, December 2, 2014

Yammer SSO gotcha - ADFS certificate autorenewal

This is a fast publish post, it is subject to change. - 12/2/2014

My organization uses Active Directory Federation Services (ADFS) to enable federation with Office365, as well as some other services.  O365 started warning about the signing certificates upcoming expiration a few weeks ago, and our investigation resulted in us determining that this is an automated process which O365 should handle gracefully.

Fast forward to last week, Thanksgiving (naturally), and Office365 is seeing our ADFS updated cert just fine.

Fast forward to Monday, and Yammer Single Sign-On is no longer working.  After doing some investigation with Yammer's DSYNC application (not SSO related, but it had some issues as well) and then looking at the Yammer configuration in ADFS, everything seemed happy.  I decided to dig into Yammer's support documentation, since I knew the ADFS certificate used for signing our SAML tokens was updated.

Per the Yammer SSO Implementation Guide, the certificate needs to be updated with Yammer Support manually. In this case, a MS Premier case was needed to get this accomplished.  Provided we have advance knowledge this is coming in the future, we could probably get away with a lower cost change method going forward.

Yammer Support needs the new ADFS Token Signing certificate.  Open up the ADFS console, browse to Service > Certificates, and select the new Token-Signing certificate (highlighted below).

 View this Certificate, go to the Details tab, and click Copy to File...  This opens the Certificate Export Wizard.  Click Next > to get the export format selection page of the wizard. Select DER encoded Binary X.509 (.CER)

Pick a file path to save the exported certificate, then ZIP it and send it to Yammer Support.  .CER files commonly come across as unsafe attachments in outlook, thus the need to ZIP it.)

Once Yammer has the cert, have them verify the details.  They need the current ADFS Token Signing certificate for your ADFS environment.  I mistakenly send them the Token Decrypting cert, thus exacerbating a production outage. :(

The moral of the story:  ADFS uses a lot of certificates.  O365 will autorenew (gracefully in our case, your mileage may vary), but Yammer requires intervention and planning if you're using SSO.  I would guess the same goes for any third party federation that uses SAML2 instead of native ADFS.