Built-in MDM for Office 365 is launched!

MDM Philosoraptor

Fantastic news follow nerds….one of my must have features for 2015 has been launched! I am super excited about this one and I believe that it will help give many new customers the peace of mind and confidence to start moving to Office 365 in earnest.

One of the great things about Office 365 is that you can get to your corporate data from anywhere, on any device. This is what users expect in todays modern world, and Office 365 lets us give our users the functionality they expect. However the services greatest benefit was also its greatest drawback. How can we make sure that data is secure if users can access it from anywhere. The answer to this before today was to either;

a. Use Microsoft Intune to control access to specific, enrolled devices. This came at additional cost and was a hard sell if a company had already got in bed with a different MDM provider.

b. Use ADFS and Conditional Access Policies to control access. This functionality was limited in scope and took away an awful lot of the benefits of Office 365 from a portability perspective.

c. Use the only control method available to try to limit data leakage; Exchange ActiveSync Quarantine. The problem with this is that it only applies to ActiveSync connections, and cannot control OneDrive for Business use. It also lacks granularity with regards to compliance.

Yesterday, the Office team announced that built-in MDM will be rolled out to all Office 365 commercial plans over the next 4-6 weeks. I am on the First Release program (http://doubledit.co.uk/2015/01/08/office-365-first-release-program/) and have not got the feature yet, but as soon as I do I will be playing around and reporting back!

The main features are as follows:

Conditional Access – this ensures that only managed, compliant devices can connect to your corporate data. This is the biggie and helps us control which mobile devices can access data stored in Office 365, not just Exchange Online.

Device Management – Jailbreak detection, PIN lock controls and rich reporting.

Selective Wipe – Remove corporate data from a managed device while leaving personal data in place.

For those wanting more advanced capabilities such as VPN/Wi-Fi profile management, PC Management and Mobile App management, InTune is still the go to Microsoft product.

You can find out more about the MDM capabilities being rolled out to Office 365 customers at the official blog here: http://blogs.office.com/2015/03/30/announcing-general-availability-of-built-in-mobile-device-management-for-office-365/

Modify AADSync Default Schedule

When using the AADSync tool to synchronise your Active Directory environment with Azure Active Directory (AAD), the default schedule for an incremental sync is 3 hours. This is done using a Scheduled Task. There are many reasons why you may want to change this schedule; maybe you have a high rate of change in your AD environment and you need a 1 hour sync to keep Office 365 up to date, or it might be that you have such a slow rate of change in your AD environment that you only want to sync your identities once every few days. It is worth mentioning that Password Synchronisation does not follow this schedule and is done immediately following a change of password, so this shouldn’t play a part in your decision to modify any scheduling of sync tasks.

Whatever your reasons, you are likely to become a little befuddled when trying to modify the regularity of your scheduled task. If you go into Task Scheduler, find the Azure AD Sync task and go into Properties, you can change the frequency of the task to make it run more or less often. However when you try to save the task it will ask you for the password of the account under which the task runs, the name of which looks something like ‘AAD_a6a4cefedc741’. It uses a random hex code at the end of the name so this could be slightly different to the example I’m using.

Modify AADSync Schedule

This account is used to run the AADSync service, is the account used to access the MIIS client database, and also to run the Scheduled Task. It is a local account which is created during the initial installation of AADSync, and the password is randomly generated. It may be tempting to change the password of this account, but please don’t. I have only come across this happening twice but both times have involved the internal database becoming completely inaccessible, meaning that the service simply won’t start, even with correct credentials.

If you really must change the frequency of your sync, create a new Scheduled Task and configure it to run the following application:

“C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCMD.exe”

Ensure the Task is running with the highest possible priveleges and configure the task to use a user account which is a member of the following groups:

  • ADSyncAdmins
  • ADSyncBrowse
  • ADSyncOperators
  • ADSyncPasswordSet

This new task will run under whatever schedule you fancy, and for good measure you can disable the original task if you’d like. When dealing with default configuration items in any piece of software, I would always recommend creating cloned configurations rather than modifying the default, as it gives you a way to back out of changes and allows you to compare old with new.

The operation couldn’t be performed because object ‘EXCHANGE\First Storage Group\Mailbox Store (EXCHANGE)’ couldn’t be found on ‘DC.domain.local’.

A most inventive and amusing title to this post, if I do say so myself!

After installing Exchange 2010 into a legacy Exchange 2003 environment, you may be faced with the following error when viewing the properties of an Exchange 2003 mailbox in the Exchange Management Console. In addition to this, if you attempt to migrate a mailbox to Exchange 2010 from 2003, you may see this error:

Mailbox database “EXCHANGE\First Storage Group\Mailbox Store (EXCHANGE)” doesn’t exist.

This is a permissions issue, and the fix is relatively simple:

1. Log into your Exchange 2003 server and open the Exchange System Manager (affectionately known as ESM).

2. Go to the properties of the Mailbox Store mentioned in the error message:

Mailbox Store Properties

3. Go to the Security Tab of the Mailbox Store and select the Advanced option. Tick the box to ‘Allow inheritable permissions’ , and Apply your changes.

Mailbox Store Properties

4. If this doesn’t fix your problem, or if the ‘Allow inheritable permissions’ box is already ticked, then do the same thing (Advanced settings under the Security tab, make sure the ‘Allow inheritable permissions’ box is ticked) but to do this, go into the Properties of the server itself, not the Mailbox Store.

5. If even this doesn’t work, then you should manually add in the Exchange 2010 server into the permissions group for the Exchange 2003 server and give it Full Control.

 

Hope this helps!

Exchange 2013 Cumulative Update 8 now available

Exchange 2013 Logo

Exchange 2013 CU8 has been made available to the general public as of 17th March 2015. Along with the usual bug fixes, a few minor new features have been announced. From my point of view, the best new feature must be the automatic profile migration for Exchange Active Sync clients when being migrated to Office 365. This was the last piece in the puzzle of Office 365 migration as far as automatic reconfiguration goes, so I’m happy to see this included.

For a full list of updates and bug fixes, you can check out the Exchange Team Blog post at http://blogs.technet.com/b/exchange/archive/2015/03/17/announcing-cumulative-update-8-for-exchange-server-2013.aspx

Download link: http://www.microsoft.com/en-us/download/details.aspx?id=46373

Thanks for reading 🙂

Office 2016 Preview & Skype for Business

Big news today from the Office team!

The Office 2016 IT Pro and Developer Preview is now available! This is a very early build however those who choose to use the preview will receive updates and new functionality along the way, much like the Windows 10 Technical Preview. From an Office 365 point of view there are some lovely new features such as MAPI/HTTP built into Outlook, much better deployment and update management options for Click to Run deployments. If you want to grab the Preview, you can log in or sign up for a Microsoft Connect account and get your grubby mitts on it!

More information can be found here: http://blogs.office.com/2015/03/16/announcing-the-office-2016-it-pro-and-developer-preview/

In other news, the Skype for Business Preview has also been announced. This is the replacement for the Lync client and has been forthcoming for some time now. The concept is to bring the Skype experience to Office 365 customers, whilst retaining the Enterprise features which make Lync such a popular product, much like OneDrive and OneDrive for Business. Just like the Lync client, this will be built into Office 2016, however this product is much further down the development timeline and will be rolling out to Office 365 Lync Online customers starting next month!

The announcement can be found here with further information: http://blogs.office.com/2015/03/16/get-ready-for-skype-for-business/

Office 365 MSOnline PowerShell and Proxy Servers

If you administrate Office 365 regularly, especially from different locations, you may well have seen this error:

There was no endpoint listening at https://provisioningapi.microsoftonline.com/provisioningwebservice.svc

The number one cause for this error is a proxy servers. The likely cause is that your Internet Explorer browser has a proxy server configured. If this is in the format of a .pac file, you will need to go into IE>Internet Options>Connections>LAN Settings and remove the Proxy entry. Your connection will now be successful.

However if you have a proxy server manually set to a specific server, you need to tell PowerShell to go via the proxy. First though, check your winhttp configuration by running CMD as Administrator and running the following command:

netsh winhttp show proxy

This will probably show the following result:

netsh winhttp show proxy

Now run the following command:

netsh winhttp import proxy ie

This will import your proxy settings into your winhttp configuration and PowerShell should now navigate through the proxy and (hopefully) get to Office 365. Remember to restart PowerShell before attemping this! If this still doesn’t work, try removing the proxy settings in IE completely and retrying. If even this doesn’t do it, then you likely have a web filter blocking your traffic, in which case you will need to make sure the Office 365 IP addresses and/or URLs are allowed through your filter.

A lot of the above information depends on your network configuration and whether you are using transparent proxies or not, so information may not be 100% accurate to your specific setup. If you end up with incorrect winhttp settings and need to reset to defaults, run:

netsh winhttp reset proxy

from an Administrative CMD prompt and you will be back to square one.

Hopefully this helps some of you suffering from issues when trying to connect to Office 365 PowerShell.

Exchange 2010 Update Rollup failed – error 1603

If you’ve never seen this error code before when installing Update Rollups for Exchange 2010, then you haven’t lived. There’s plenty of blogs and articles out there about it, but I wanted to record it for my own purposes so I don’t go trawling for the answer next time!

In a nutshell, the reason this happens is that UAC hates you.

Simple fix to this is to run CMD as Administrator, and use msiexec to install the Update Rollup, like this:

msiexec /update Exchange2010-KB2961522-x64-en.msp

Gotchas? Well the file should be on a local drive (not a network share). If you are still having problems after this, take a gander at the following KB article: http://support.microsoft.com/en-us/kb/2784788/en-us

That’s about it. Happy Update Rollup’ing!