Latest Entries »

Fidget with a touch screen long enough and you may stumble across some hidden gems. Apparently Microsoft has hidden some features inside their mobile Office 365 admin app that make the app even more useful. If you go to Settings on the app and tap on the Version 5 times, then More Settings will show up!

















So what features are they hiding? Quite a few. You can update the Color (to Orange…only…), view Partner tenants, edit Groups, add Aliases (for cloud-only accounts), view Permissions, check Migration stats and view Mobile devices assigned to users:



































You’ll notice Partners is missing, which is due to confidentiality. A “Mobile Devices” screen print is also missing, because I didn’t get valid results on that section. I’m guessing these features are hidden for a reason (i.e. not ready for production), so I’m making no claims to the full functionality of any of it. Lastly, remember that aliases for synchronized accounts cannot be added from Exchange Online at this time; that limitation exists for the mobile app the same as it exists for the Exchange Admin Center.

For those that don’t know, this app is available for iOS, Android and Windows mobile devices at their corresponding app stores.

Very cool new features, but bad timing…giving me the opportunity to run Office 365 from the golf course doesn’t do me any good when the snow is coming!







Office 365 has (finally) released limited administrative roles to allow restriction of accounts to specific technologies within the suite. No more need to add your SharePoint and Exchange admins to the Global Administrator role!  The setup is intuitive, as it should be, although the updated details around the different roles still haven’t been published (MS link takes you here).


Created with Microsoft Fresh Paint

I am an organizer for the Microsoft Messaging and Collaboration User Group, based out of the Chicago area (currently), and will be presenting on Intune MDM administration and end-user experience on June 10th at the Netrix office in downtown Chicago.  For those that are interested in seeing this content, or learning about Exchange 2016 from my colleague (and Exchange MVP) Damian Scoles, I encourage you to register at our site: MMCUG Meetup Site

We will offer a remote attendance option via a Skype meeting but, for those that can attend in person, there will be food/beverage available and we will also be giving away a Microsoft Band! We hope to see you there, in-person or remotely!

Microsoft has released a preview for a new Azure AD Premium feature set to manage administrative access to Azure, called Privileged Identity Manager (PIM).  According to Microsoft, “This is an Azure AD Premium feature that improves your organization’s cloud security posture by reducing risk from users who have access to highly privileged roles, such as administrator roles in Azure AD and other services such as Office 365, Intune, and SaaS apps whose access is managed by Azure AD” (

Azure AD Privileged Identity Management reduces this risk by enabling you to:

  • Discover and monitor privileged roles. The Azure AD PIM Dashboard gives you visibility into and tracking of users with privileged roles.
  • Automatically restrict the time that users have these privileged permissions through on-demand “just in time (JIT)” activation of permissions for pre-configured time windows.
  • Monitor and track privileged operations for audit purposes or security incident forensics.

Very cool, and not available with any other identity management solutions for Azure or Office 365; I want this blog to serve as more than a regurgitation of what you can already see in the TechNet article, though, so let’s dig a little deeper.

Firstly, the article directs you to add the Azure AD PIM service from the Marketplace through the Azure Preview Portal (, which is important.  If you try to look for this service in legacy Azure portal (, you will not find it. For those that have avoided getting acclimated with the preview portal, I suspect more and more of the newly released features within Azure will only be available here, so it’s a good time to start getting used to it! Also, in case you didn’t catch it at the beginning of the blog or within the TechNet article, this is for Azure AD Premium subscribers only. Lastly, this is still in Preview mode, meaning any support for it is best effort (if at all); any implementation of this feature set should be considered for testing purposes only.

There are two basic ideas to PIM, which are assigning roles and activating roles.  You assign the role to the user, and then they activate that role when they need the privileges that it contains. This allows users to maintain the ability to use administrative accounts without having those accounts maintain permissions permanently, preventing unknown exploitation of that account.  The intent of this feature set, at this time, is not to prevent the user/account from having administrative access, but to ensure that administrative access is temporary, monitored and reported on without manual intervention being required. Per Microsoft: “During this preview, a user enters a business justification (“request reason”) in the form of free text. While no meaningful validation is enforced today, the business justification it is logged and shows up in the audit experience along with the other details of the historical events. You can use it forensics or for detecting compliance issue with company policy, such as a policy that requires providing business justification like an incident number that needs privileged access to resolve. In [the] future, the business justification could be used for stronger validation by an authorization workflow.” I would bet on workflows showing up in the near future, if my bookie would take bets on such things, but MFA is also a good way to ensure even short-term exploitation of administrative access can be avoided.


Right now the ability to configure properties for 6 different roles exists:

  • Global Administrator
  • Billing Administrator
  • Service Administrator
  • Password Administrator
  • User Administrator
  • Security Administrator

These are the built-in Azure Active Directory roles, but future updates will expand the reach of PIM in to additional privileged roles. You can see there are already some robust options for configuring the existing roles:


Additionally, you can click on the Roles tile to manage user assignments for privileged roles. You can view all privileged identities by role or name, add or remove users from privileged roles, make the assignments to privileged roles either temporary or permanent, or activate someone into their assigned privileged role, on their behalf (per the TechNet article).

The reporting is pretty detailed, as well (though my initial testing doesn’t have a lot of detail to provide). I like the ease of access to the information, at a glance, with the ability to sort on the fly.


I’m still looking in to the ability to export any of this data, as well as any PowerShell capabilities, but this is a great start to a very useful tool! I’m looking forward to its growth, and it’s great to see Microsoft continuing to increase the value proposition for Azure AD Premium, while simultaneously pulling some of the “older” features in to the free version.


I recently had a client request to ensure that users could not access Office 365 unless they were using internal resources, or part of a special Active Directory group, due to questions around over-time pay and access to email from “home”.  While there are many blogs out there (and TechNet articles) that reference ADFS claims, we had a bit of trouble getting ours to work correctly, so I thought I’d post it here to potentially save others from the hassle.

The gist of the rule is that, within ADFS, a custom claim exists that says if the client IP address is not within the accepted range and the user is not a member of the Active Directory group, then deny access.  The next rule is the default rule to Allow All; so, unless the users are explicitly denied, they will be allowed.

A few things to remember about this rule:

  • It blocks any Federated User authentication from the “outside”, including (but not limited to) ActiveSync, OneDrive for Business/SharePoint Online, Azure Management and Intune.
  • If you use a VPN connection, review your routing to see what IP address is being passed as the forwarded client IP address – routing may need to be updated if you’re being passed through a proxy.  The Event Viewer will generate events that show the variables being passed upon an authentication failure.
  • The Group SID will need to be identified for whatever your “special AD group” is and used within the rule.

The setup basically looks like this:























I’ve accounted for every “internal” IP range, as the client had them all.  It may be acceptable for you to remove some of those ranges to keep the claim rule more concise.  And, for those that like to avoid typos, here’s the text version for ease of copying and pasting:

exists([Type == ““])

&& NOT exists([Type == ““, Value =~ “\b12\.132\.194\.220\b|\b192\.168\.100\.\d{1,3}\b”])

&& NOT exists([Type == ““, Value =~ “S-1-5-21-1644994857-2635182024-3156839653-8227”])

=> issue(Type = ““, Value = “true”);

When setting up Intune to manage mobile devices, within the web portal, there comes a point when you have to define your Mobile Device Management (MDM) Authority.  This is a very important decision; according to TechNet, “Consider carefully whether you want to manage mobile devices using Intune only or System Center Configuration Manager with Intune integration. After you set the mobile device management authority to either of these options, it cannot be changed again.” (

So, is that true?  Once I configure Intune to be the authority, I can never later decide to integrate with SCCM? Actually, you can switch, it just may be painful to do so. If you open a ticket with Intune support, they will assist you in resetting your MDM Authority setting.  What’s the process, you ask?  Great question!  You basically have to remove all of your existing configuration within Intune before the support team will take action – not something easily accomplished if you already have a production implementation embedded within your organization.  Below are the specific instructions, provided by Intune Technical Support, before I was allowed to switch my settings:

Important Note: If any of the items below are not completed, the leftovers on Intune account will conflict with SCCM and will require further instructions to fix.

1. Retire all Modern Devices (mobile devices) from within the Windows Intune Admin Console.

– It is important that you do not attempt to retire a device from the device itself for this procedure to be executed. Let support know if any devices are stuck in a “pending state’.

2. Delete the Service To Service Connector (under Administration > Mobile Device Management > Microsoft Exchange). Or Disable the Exchange Connector if you have set that up.

3. Remove any side-loading keys from the Windows Intune Admin Console.

4. Delete the iOS APNs certificate in Administration > Mobile Device Management > iOS page.

5. Delete any and all published applications that are for MDM Devices in Software > Managed Software. NOTE: You will not be able to delete the Company Portal App, aka Self Service Portal (SSP), because it can only be replaced.

Once these steps are completed, Intune Technical Support can continue from our side and have your MDM Authority switch from Microsoft Intune to CM. The complete time for this procedure normally takes 2 – 3 business days to complete, but it does depend how busy our Engineers are to reset your MDM Authority switch from Microsoft Intune to CM. Once that is completed, you will be notified from our Engineers that your MDM Authority has been reset.


And that’s it! 3 days later I was asked again to define my MDM Authority, allowing me to select SCCM and move forward with the internal integration.

I just finished resolving an issue with an Exchange 2007 SP3 RU15 on-prem environment, using Exchange 2013 for the hybrid coexistence server with Exchange Online, where they were unable to view Free/Busy information in either direction.  Here are the details:

  • Single Exchange 2013 CU7 hybrid server
  • Global setup of Exchange 2007 SP3 RU15 servers (number doesn’t really matter)
  • Alternate ID deployed, setting primary SMTPasUPN in Office 365
    • for UPN
    • for primary SMTP was not an owned domain name, so only was registered within Office 365.

The hybrid wizard completed successfully with no issues.  A mailbox was migrated successfully and able to log in to webmail, but the Outlook client would not automatically update.  From webmail, no free/busy information could be gained through the Calendar.  Here were some tests we ran:

  • Get-OrganizationRelationship (on both sides): Success
  • Test-FederationTrust: Success
  • Get-SharingPolicy: No evident issues
  • RemoteConnectivityAnalyer
    • Outlook Autodiscover (on-prem user): Successful
    • Outlook Autodiscover (migrated user): Failed w/ 401 Unauthorized error when attempting Autodiscover
    • Test Free/Busy: Failed w/ 401 Unauthorized error when attempting Autodiscover

We reset the Autodiscover virtual directory on the hybrid server to ensure there were no IIS problems there, but got the same results.  We checked the Loopback settings, as brought up here:

Days of troubleshooting later, it finally clicked: Autodiscover is passing through the local UPN, which is not an accepted domain in Office 365.  Once the UPN was updated to reflect, Autodiscover started to respond in the expected manner.  So, a big note for Alternate ID considerations – if you do not register the UPN (e.g. it is non-routable or un-owned), Free/Busy coexistence and Autodiscover will not work as otherwise documented.

Hopefully this helps others that may be considering Alternate ID to avoid hybrid headaches!

Update: My friend Jesper Stahle (@JesperStahle) appropriately noted that support for Alternate ID has been flagged for being troublesome already.  Explore the details within; “If you read the “Important” note, you see the statement. The issue is that local Autodiscover ask one UPN and EXO another”.

Thanks, Jesper!

For those looking to manage mobile devices in tandem with Office 365, Microsoft provides a couple of different solutions.  For data-specific considerations, RMS/IRM provides the capability to encrypt files so that unauthenticated users (e.g. non-employees or ex-employees) will not be able to open the file itself.  For device-specific considerations, Intune provides Mobile Application Management policies that can restrict a user’s ability to fully navigate between managed and non-managed applications.  For example, you can stop someone from opening an Excel spreadsheet in OneDrive for Business (OD4B) and saving it to their personal OneDrive app.  The end-user experience is still not ideal, but there certainly is growing value to looking at Intune for device management. Let’s take a look at how to set it up.

1. Get an Intune tenant, tied to the related Office 365 tenant.  There are 30-day demos available for Intune, as well as Office 365.

a. Create a security group with specifically defined users for testing ahead of time – my group is called Restricted. This will be used later for applying policies.

b. Follow the process here for preparing the manage mobile devices using Intune:

2. Publish software!  Currently, there are only Software Management templates available for Android and iOS. Publishing software for iOS is easy:

a. First find the software you want to publish in the Apple App Store, then find the Copy Link option for that app.  I am showing OWA for iPhone here, but Excel will be used for the Mobile Application Management demonstration.


b. Go to Software -> Managed Software -> Add Software to start the publishing wizard.  Make sure “Managed iOS App from the App Store” is selected, and then add the link copied in the previous step.


c. Put in your preferred description for publishing, which will be seen in the Company Portal (where managed software is downloaded from).  Icons will need to be provided (which can be kind of painful when publishing lots of applications).  I’m displaying this as a featured app to ensure it is highlighted and easily found for end users.


d. Select which iOS devices the software can be installed on.  The app store has some software that’s the same for iPhones and iPads (e.g. Excel), and some that’s not (e.g. OWA).  This will prevent users from attempting to install unsupported software on the wrong device.


e. Complete the update – you can see here that I’ve added most of the Microsoft suite for the purposes of this demonstration (sorry, OneNote).



3. Create a new Mobile Application Management (MAM) policy – again, only available for Android and iOS at the time of this posting.

Intune-SoftwareManagementTemplate4. Configure your MAM policy – here’s the cool part!  You can see I’m preventing backups to alternate locations, allowing only managed apps to transfer data to/from each other, preventing “Save As” to stop file type and/or file location changes and restricting cut, copy and paste outside of managed apps.  At the time this posting, only Word, Excel and PowerPoint are supported in regards to Office apps, so keep that in mind when looking at options like PIN access (I set mine to No after taking these screen shots).  Lastly of note, I’ve configured the access requirements to allow for 12 hours of offline access to managed application data before authentication is again required.

Intune-MAM1 Intune-MAM2


5. For iOS devices, to prevent document transfer between managed and unmanaged apps, you must also configure and deploy a mobile device security policy that disables the setting Allow managed documents in other unmanaged apps.

6. Deploy the new software to the Company Portal. Go back to Software -> Managed Software -> Manage Deployment and add the app to the newly created Configuration Policy.  You can also see here that I’ve applied the settings to the Restricted group that I referred to back in Step 1:




7. If you want to force use of the Company Portal, ensure you have Conditional Access configured for Exchange Online.  The Company Portal installation is the pre-requisite to ensuring compliance, which means that any user who has not installed the Company Portal will not have access to Exchange Online.  Yes, currently this would technically allow for a user to access OD4B separately without conditional access, but SharePoint Online support will be available (it disappeared sometime between 12/15/14 and 12/16/14, but I’d expect it back up soon).


8. Enroll the device by installing the Company Portal app and log in.  I will note that I was unable to connect using a federated account (using ADFS 2.0), so there are still some bugs to work out.

Intune-Enrollment1 Intune-Enrollment2 Intune-Enrollment3














9. Install managed software – and bask in the glory of effective compliance!












Whoops!  No apps show in the Company Portal!  The only way I was able to get Managed Applications to work correctly was to force their installation through the individual deployments, and the only option available for Deadline was “As soon as possible”.  This will force an immediate download on managed devices, which therefore requires careful consideration for data usage; my device waits until I’m on WiFi for large files, but that cannot be guaranteed in all BYOD scenarios.

Update (12/17/14): This (lack of) functionality is confirmed by Microsoft – current licensing issues are preventing publishing of Apple apps through the Company Portal.  Resolution of this issue is in progress.



So it’s not all ironed out, but after forcing an Excel installation on my managed iPhone, the policy did work as configured.  Notice I cannot Email, copy a link, nor Save to unmanaged locations:

Intune-Excel1 Intune-Excel2

Links for additional information/guidance:

Check out the latest TechNet blog – Intune functionality is finally becoming competitive! Bring on the data segregation and Office 365 focused configuration policies!

After installing Exchange 2013, moving DNS records for Exchange (Autodiscover, OWA, etc.) and after installing the patch needed for Exchange 2013 CU6 and Exchange 2007 coexistence (, I had multiple users experiencing issues syncing with their mailboxes on legacy server using exchange ActiveSync when connecting through the Exchange 2013 Server.

We would log the following error in the HTTP Proxy Logs (obviously edited): 2014-11-20T15:30:30.754Z,3967c101-926d-48f5-a3ed-460a306e5bdd,15,0,995,12,,Eas,<owa>.<domain>.com,/Microsoft-Server-ActiveSync/default.eas,,Basic,True,\,,Sid~S-1-5-xx-283xxx7490-397xxx470-315827xxx2-2550,Apple-iPhone5C1/1104.257,,01,400,400,,POST,Proxy,<owa>.<domain>.com,15.00.0995.000,IntraForest,WindowsIdentity,Database~06b7acba-c162-4868-b06c-f061a85ec67f~~2014-12-20T15:30:30,,,987,346,232,,0,0,,0,,0,,0,0,,0,31.2493,16,0,0,0,25,0,0,0,0,0,28,0,26,19,19,19,44,?User=&DeviceId=ApplDNRJRWM4DTTN&DeviceType=iPhone&Cmd=Sync,,BeginRequest=2014-11-20T15:30:30.723Z;CorrelationID=;ProxyState-Run=None;;ResolveCasLatency=0;FEAuth=BEVersion-1941996515;BeginGetRequestStream=2014-11-20T15:30:30.739Z;OnRequestStreamReady=2014-11-20T15:30:30.739Z;BeginGetResponse=2014-11-20T15:30:30.739Z;OnResponseReady=2014-11-20T15:30:30.754Z;EndGetResponse=2014-11-20T15:30:30.754Z;ProxyState-Complete=ProxyResponseData;EndRequest=2014-11-20T15:30:30.754Z;,WebExceptionStatus=ProtocolError;ResponseStatusCode=400;WebException=System.Net.WebException: The remote server returned an error: (400) Bad Request.    at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)    at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass2c.b__2b();

This would suggest an HTTP 400 was issued by the Exchange Backend Website

Exchange Backend would log the following errorUser=<email address>&DeviceId=ApplDNRJRWM4DTTN&DeviceType=iPhone&Cmd=Sync&Log=PrxTo:legacy.<domain>.com_PrxFrom:fe80%3a%3a61f5%3a24f9%3a7251%3afcec%2516_V121_HH:<owa>.<domain>.com_SmtpAdrs:<email address>_Mbx:<server>.<domain>.com_Dc:<domain controller>.<domain>.com_SBkOffD:L%2f-470_TmRcv00:07:52.3668044_ActivityContextData:ActivityID%3d1e3df9cf-0597-4ad7-8fc6-887ce2f788ba%3bI32%3aATE.C%5b<domain controller>.<domain>.com%5d%3d1%3bF%3aATE.AL%5b<domain controller>.<domain>.com%5d%3d0%3bI32%3aADS.C%5b<domain controller>%5d%3d1%3bF%3aADS.AL%5b<domain controller>%5d%3d9.9439%3bI32%3aADS.C%5b<domain controller>%5d%3d1%3bF%3aADS.AL%5b<domain controller>%5d%3d8.0323%3bI32%3aATE.C%5b<domain controller>.<domain>.com%5d%3d1%3bF%3aATE.AL%5b<domain controller>.<domain>.com%5d%3d0%3bS%3aWLM.Bal%3d480000%3bS%3aWLM.BT%3dEas_Budget:(D)Owner%3a<domain>%5c<user ID>%5FApplDNRJRWM4DTTN%5FiPhone%2cConn%3a0%2cMaxConn%3a10%2cMaxBurst%3a480000%2cBalance%3a480000%2cCutoff%3a600000%2cRechargeRate%3a1800000%2cPolicy%3aGlobalThrottlingPolicy%5Fa2045d2e-f0d3-4e76-a152-3a2ea8e50a21%2cIsServiceAccount%3aFalse%2cLiveTime%3a00%3a00%3a00.0156267_

The log above suggests we are supposed to proxy this request to legacy.<domain>.com, however we don`t see the corresponding hit in the IIS Logs on the Legacy Server. Considering the affected set of users are members of multiple groups we suspected this could be a Kerberos Token Bloat resulting in proxy failures.

We configured we following registry keys on the Exchange 2013 and legacy servers, after which we Reset IIS and Netlogon Service: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

  • Type: DWORD
  • Name: MaxRequestBytes
  • Value: 16777216


  • Type: REG_DWORD
  • Value: 48000
  • Name: MaxTokenSize


  • Type: DWORD
  • Value: 65534
  • Name: MaxFieldLength

This resolved the issue for us; I hope this helps others that may run in to this issue.