Friday 18 January 2019

InTune for Chromebook Admins (p3).

Application Deployment.

In the last of three posts we take a look at application deployment using InTune for Education in a SaaS based school

Intune for Education (IT4E) can be used to deploy three types of application.

Web Apps. These are no more than shortcuts to web sites. If you have an externally hosted learning platform or any application that has a web front end you’ll use the web apps option to deploy the link.

Microsoft Store Apps. This feature allows you to install apps from the Microsoft Store for Education. All store apps use the Universal Windows Platform (UWP) which is a unified format for Windows 10, Windows 10 Mobile, Xbox One and HoloLens but not Windows 7. Therefore the school needs to be running Windows 10 to pull apps from the store. However since you also need Windows 10 for IT4E the two requirements go together.

Desktop Apps. Also known as Line of Business apps in the InTune console and probably Legacy Apps in the not too distant future.  The file extensions for Windows apps include .msi, .appx, .appxbundle, .msix and .msixbundle.

Deploying Apps.
Applications are allocated in the same the way as policy, through a hierarchy of groups. This strategy is a little more flexible than the Google approach which has only just started to adopt group based application deployment.  Another area where the Microsoft approach differs from Google is the ability to assign applications to devices. This has no counterpart in the Google world where user and device policies are strictly divided.

The application set that’s delivered to the user session is a combination of all the groups that reference both the user and device. If an installed application falls out out scope when a user or device is removed from a group the application will uninstall on the next policy refresh.

The end result is much the same as general policy management, you have great flexibility but this power comes with the ability to tie yourself into knots if you don't have a plan to start with.

First impressions working with app deployment in IT4E is that some tasks are really easy and other tasks are impossibly hard.

On the easy side, deploying a Desktop App is a very slick process.  Fill in a simple dialog in IT4E and select the installer file (see above). The file itself is uploaded to a central data store within Azure which is provided as part of the platform and then pushed down to the user/device groups on a policy refresh. This works surprisingly well allowing for the time to reset the policy and to transfer the .msi data package. Web Apps behave in the same way except that everything works a little quicker as there’s no install package to move about.

Although the process allows you to select an icon for the application this only shows up on console itself and doesn’t get pushed down to the device as you might expect. This irritation will probably get fixed at some stage.

Deploying apps from the Microsoft Web Store requires an initial effort to set up the Store account for the school. Currently this can only be achieved using the Intune Azure interface rather than through IT4E. Until the store account is linked back to Azure the option remains greyed out in IT4E.

Once the account is activated the process involves selecting the app from the store interface and then synchronizing it with the InTune database so the application displays on the IT4E console. Once that’s done you are presented with the same group allocation model you have with Web Apps and Desktop Apps.

The synchronization between the Store and InTune runs as a background process so it’s unlikely that the app will immediately display in the IT4E console, just give it a little time. The full Intune Azure interface has an option to force a sync which is a benefit for impatient admins and it would be nice to see this feature in IT4E as well (above).

If these are the easy bits - what are the difficult bits?
  • You can’t install from a .exe file, a common format for legacy software and drivers.
Update: It's now possible to deploy Win32 apps in .exe format but only using the fully featured InTune portal in Azure, not IT4E.
  • You can’t place a link onto the desktop to create a customised user experience or do anything in the way of file management.
  • You can’t map Windows file shares.
  • Print support is underdeveloped at the moment.

Currently the solution is to create a Powershell package deployed through InTune or create an .msi wrapper. In fact just about anything is possible if you are willing to spend some time scripting but why make it so difficult ?

The answer lies with Microsoft's cloud focused vision. In the future you’ll be unlikely to map Windows file shares - you’ll use OneDrive. You won’t sideload local apps, you’ll download them from the Microsoft store or consume SaaS.  You won’t disseminate information by printing, you’ll share, publish and collaborate using Teams and you won’t be able to use the desktop as a filestore because the vision is cross platform.

These things are hard because by adopting the easier options you’ll be nudged towards Microsoft's cloud wonderland.

In conclusion let’s return to our Google administrator living in an alternative reality who has the job of integrating Microsoft's emerging technology into a serverless SaaS based school.

What are the principal features of Microsoft modern management platform that a Chromebook admin will have to come to terms with ?

  • A cloud based platform managed through a web interface without any dependency on local infrastructure.
  • Locally installed applications delivered using a store model.
  • Simple “lifetime” device level licencing as an option.
  • Close integration with a cloud based productivity platform to deliver LOB applications.
  • Strict application control limited to web links and store apps with restricted support for side loading.
  • A updated security model based on web open standards with backend integration into common SaaS platforms.
  • Reliance on a cloud based user directory that all also supports groups and devices.
  • Security patches and updates delivered centrally on a predictable release schedule.
  • Management controlled through a hierarchical policy set.

Does any of this sound familiar?  I suspect it won’t be too hard.

No comments:

Post a Comment