Microsoft Intune is rocking at the moment with many new features added this week. Microsoft have committed to quarterly updates to the service and the road-map looks strong. I've already blogged on some of these new features but I wanted a central location for these blogs. I will add to the list as new features are released.
Note that these particular blogs are relevant for stand-alone Intune only. The availability of the features in the unified SCCM 2012/Intune solution is typically 90 days behind.
A list and description of the latest features (December 2014) can be found on the Microsoft Intune blog
http://blogs.technet.com/b/microsoftintune/archive/2014/12/09/new-mobile-application-management-capabilities-coming-to-microsoft-intune-this-week.aspx
Intune Features
Conditional access to email with Microsoft Intune
Microsoft Intune Kiosk mode
Blacklist applications on mobile devices with Microsoft Intune
Gerry Hampson Device Management
Thursday, 11 December 2014
Tuesday, 9 December 2014
Blacklist applications on mobile devices with Microsoft Intune
Back to Microsoft Intune menu
This has also been an eagerly awaited feature in Microsoft Intune. Now we can blacklist and whitelist applications that can be installed on mobile devices.
The following levels of support are available:
Windows Phone 8.1 or later: you can specify blocked applications or you can specify only applications that can be installed. The user will not be able to install blocked applications.
Android 4 or later: you can specify a list of applications that are compliant (or not compliant). Non- compliant applications can still be installed but will be reported as non-compliant in the Noncompliant Apps Report.
iOS: you can specify a list of applications that are compliant (or not compliant). Non- compliant applications can still be installed but will be reported as non-compliant in the Noncompliant Apps Report.
Lets have a look at a managed Windows Phone 8.1 device. The blacklisting/whitelisting works really well.
First we have to create the policy. Navigate to Policy > Configuration Policies.
Click to Add a new policy and choose Windows > Windows Phone Configuration Policy. Note that is states Windows Phone 8.1 or later). Select "Create Policy".
In this case I want to blacklist all applications (except a single store app - Adobe Reader). Click to Add the app.
Enter the details.
Now Save the policy.
You are prompted to deploy the policy.
You can target a group of users or devices with this policy.
Now let's see what happens on the device.
I haven't enrolled it yet so I have to add a workplace account. After entering my details the device will be enrolled.
This is evidence that the Intune policy has been received. I have to password protect the device (I configured this earlier in the general Intune policy).
Now when I open the Windows Store I can search for Adobe Reader. See that I am allowed to install this app.
I am unable to install any other app. We get the message "The app is not available for your device. Tap here for more info."
This is the "more info". Pretty cool I think.
Note that this feature is currently available in the standalone Intune only. It is not yet available in the unified SCCM 2012/Intune solution (you can use OMA-URI for this but it is a little cumbersome).
References:
Manage devices using configuration policies with Microsoft Intune
http://technet.microsoft.com/en-US/library/dn818906.aspx
This has also been an eagerly awaited feature in Microsoft Intune. Now we can blacklist and whitelist applications that can be installed on mobile devices.
The following levels of support are available:
Windows Phone 8.1 or later: you can specify blocked applications or you can specify only applications that can be installed. The user will not be able to install blocked applications.
Android 4 or later: you can specify a list of applications that are compliant (or not compliant). Non- compliant applications can still be installed but will be reported as non-compliant in the Noncompliant Apps Report.
iOS: you can specify a list of applications that are compliant (or not compliant). Non- compliant applications can still be installed but will be reported as non-compliant in the Noncompliant Apps Report.
Lets have a look at a managed Windows Phone 8.1 device. The blacklisting/whitelisting works really well.
First we have to create the policy. Navigate to Policy > Configuration Policies.
Click to Add a new policy and choose Windows > Windows Phone Configuration Policy. Note that is states Windows Phone 8.1 or later). Select "Create Policy".
In this case I want to blacklist all applications (except a single store app - Adobe Reader). Click to Add the app.
Enter the details.
Now Save the policy.
You are prompted to deploy the policy.
You can target a group of users or devices with this policy.
Now let's see what happens on the device.
I haven't enrolled it yet so I have to add a workplace account. After entering my details the device will be enrolled.
This is evidence that the Intune policy has been received. I have to password protect the device (I configured this earlier in the general Intune policy).
Now when I open the Windows Store I can search for Adobe Reader. See that I am allowed to install this app.
I am unable to install any other app. We get the message "The app is not available for your device. Tap here for more info."
This is the "more info". Pretty cool I think.
Note that this feature is currently available in the standalone Intune only. It is not yet available in the unified SCCM 2012/Intune solution (you can use OMA-URI for this but it is a little cumbersome).
References:
Manage devices using configuration policies with Microsoft Intune
http://technet.microsoft.com/en-US/library/dn818906.aspx
Conditional access to email with Microsoft Intune
Back to Microsoft Intune menu
This has been an eagerly awaited feature and is now available with Microsoft Intune. We can now use Intune conditional access policies to control access to Microsoft Exchange email from mobile devices, even when the device is not managed by Intune.
Supported devices:
Windows 8
Windows Phone 8
iOS with Exchange ActiveSync
In the Intune Admin Console navigate to Policy > Conditional Access > Exchange On-premises.
See that you can now "Block Exchange access from mobile devices that are not managed by Intune". You will also see that the option is greyed out until you set up an Exchange connector.
To set up a connector navigate to Admin > Mobile Device Management > Microsoft Exchange > Set up Exchange Connector. There are separate processes for on-premise Exchange (requires Exchange 2010 or later) and Office 365 (requires Office 365 account with Exchange 2013 tenant).
Details on setting up these connectors can be found in this TechNet Library article. You can see, for example, what Exchange permissions your user account requires.
http://technet.microsoft.com/en-us/library/dn646988.aspx#bkmk_EX_OP
Now you can check the box to block access for unmanaged devices.You can choose the groups of users at which this policy is targeted. You can also choose groups of users that will be exempt.
This is where you configure your advanced settings. You can "Add Rule" to configure a rule that defines access levels for specified mobile device families and models. These devices can be of any type, so device types that are unsupported by Intune can be configured here.
You can also configure a default rule. When a device not covered by any of the other rules is detected, you can choose to allow it to access Exchange, block it, or quarantine it. The default rule will apply to all device types, so device types that are unsupported by Intune will be affected as well.
Specify the text to include when Exchange sends an email to users whose devices have been quarantined or blocked.
Note that this really cool feature is currently available in standalone Intune only. It is not yet available with the unified solution of SCCM 2012/Intune.
References:
Control access to on-premises Microsoft Exchange with conditional access in Microsoft Intune
http://technet.microsoft.com/library/dn818907
Conditional Access for On-Premises Exchange using Microsoft Intune
http://blogs.technet.com/b/microsoftintune/archive/2014/12/03/conditional-access-for-on-premises-exchange-using-microsoft-intune.aspx
This has been an eagerly awaited feature and is now available with Microsoft Intune. We can now use Intune conditional access policies to control access to Microsoft Exchange email from mobile devices, even when the device is not managed by Intune.
Supported devices:
Windows 8
Windows Phone 8
iOS with Exchange ActiveSync
In the Intune Admin Console navigate to Policy > Conditional Access > Exchange On-premises.
See that you can now "Block Exchange access from mobile devices that are not managed by Intune". You will also see that the option is greyed out until you set up an Exchange connector.
To set up a connector navigate to Admin > Mobile Device Management > Microsoft Exchange > Set up Exchange Connector. There are separate processes for on-premise Exchange (requires Exchange 2010 or later) and Office 365 (requires Office 365 account with Exchange 2013 tenant).
Details on setting up these connectors can be found in this TechNet Library article. You can see, for example, what Exchange permissions your user account requires.
http://technet.microsoft.com/en-us/library/dn646988.aspx#bkmk_EX_OP
Now you can check the box to block access for unmanaged devices.You can choose the groups of users at which this policy is targeted. You can also choose groups of users that will be exempt.
This is where you configure your advanced settings. You can "Add Rule" to configure a rule that defines access levels for specified mobile device families and models. These devices can be of any type, so device types that are unsupported by Intune can be configured here.
You can also configure a default rule. When a device not covered by any of the other rules is detected, you can choose to allow it to access Exchange, block it, or quarantine it. The default rule will apply to all device types, so device types that are unsupported by Intune will be affected as well.
Specify the text to include when Exchange sends an email to users whose devices have been quarantined or blocked.
Note that this really cool feature is currently available in standalone Intune only. It is not yet available with the unified solution of SCCM 2012/Intune.
References:
Control access to on-premises Microsoft Exchange with conditional access in Microsoft Intune
http://technet.microsoft.com/library/dn818907
Conditional Access for On-Premises Exchange using Microsoft Intune
http://blogs.technet.com/b/microsoftintune/archive/2014/12/03/conditional-access-for-on-premises-exchange-using-microsoft-intune.aspx
Monday, 8 December 2014
Microsoft Intune Kiosk mode
Back to Microsoft Intune menu
Kiosk mode is a really cool new feature introduced in Microsoft Intune. It's very useful for public facing devices. You can implement it by creating a custom Intune configuration policy (Android & iOS only). This blog demonstrates how to deliver kiosk mode to an Android device. The end user will only be able to launch a single application and will be unable to use the volume controls.
I have already enrolled a test Android device.
I've also added and deployed a managed application (National Geographic). It has been installed on the test device.
So, let's look at the policies. In the Intune Admin Console navigate to Policy > Configuration Policies.
Select Add to see the available templates. See that there are different templates for each device type as well as common settings.
Android
iOS
Windows
Computer Management
Common settings
We are interested in Android at the moment. Choose "Android Configuration Policy" and "Create and Deploy a Custom Policy".
Edit the policy as required. Switch On "Select a managed app that will be allowed to run when the device is in kiosk mode". Choose a managed application (note that you must have already deployed this to the device through Microsoft Intune). You can only choose one application to run on the device.
I've also chosen to disallow the use of the volume buttons.
After you've created the policy deploy it to the required users or devices.
This is my Android device before the policy is applied.
Very quickly the policy has been applied to the device. Look at the difference. Access to all apps has been removed (except National Geographic). I cannot use any of the buttons to navigate the device.
See what happens when I try to use the volume controls.
I can only launch a single managed app. This is really cool.
In order to reverse this I just have to retire the device. This removes the "kiosk mode" policy.
Retire the device.
Welcome back.
Note that this feature is not yet available in the SCCM 2012/Intune unified solution.
References:
Microsoft have published the following information in the TechNet Library
Manage devices using configuration policies with Microsoft Intune
Use policies to manage computers and mobile devices with Microsoft Intune
Also good blog post by Nico Sienaert
http://scug.be/nico/2014/12/08/assigned-access-kiosk-mode-with-windows-intune/
Kiosk mode is a really cool new feature introduced in Microsoft Intune. It's very useful for public facing devices. You can implement it by creating a custom Intune configuration policy (Android & iOS only). This blog demonstrates how to deliver kiosk mode to an Android device. The end user will only be able to launch a single application and will be unable to use the volume controls.
I have already enrolled a test Android device.
I've also added and deployed a managed application (National Geographic). It has been installed on the test device.
So, let's look at the policies. In the Intune Admin Console navigate to Policy > Configuration Policies.
Select Add to see the available templates. See that there are different templates for each device type as well as common settings.
Android
iOS
Windows
Computer Management
Common settings
We are interested in Android at the moment. Choose "Android Configuration Policy" and "Create and Deploy a Custom Policy".
Edit the policy as required. Switch On "Select a managed app that will be allowed to run when the device is in kiosk mode". Choose a managed application (note that you must have already deployed this to the device through Microsoft Intune). You can only choose one application to run on the device.
I've also chosen to disallow the use of the volume buttons.
After you've created the policy deploy it to the required users or devices.
This is my Android device before the policy is applied.
Very quickly the policy has been applied to the device. Look at the difference. Access to all apps has been removed (except National Geographic). I cannot use any of the buttons to navigate the device.
See what happens when I try to use the volume controls.
I can only launch a single managed app. This is really cool.
In order to reverse this I just have to retire the device. This removes the "kiosk mode" policy.
Retire the device.
Welcome back.
Note that this feature is not yet available in the SCCM 2012/Intune unified solution.
References:
Microsoft have published the following information in the TechNet Library
Manage devices using configuration policies with Microsoft Intune
Use policies to manage computers and mobile devices with Microsoft Intune
Also good blog post by Nico Sienaert
http://scug.be/nico/2014/12/08/assigned-access-kiosk-mode-with-windows-intune/
Tuesday, 2 December 2014
SCCM 2012 R2 - Possible Software Updates strategy
Back to ConfigMgr main menu
There is no absolutely correct way to implement a software updates strategy in your organization. Each organization is different and the correct way is the way that works for you. However, after several attempts at trying different approaches, I've decided on a method that delivers a robust solution and is easy to understand and manage. I've included some details below. I hope it makes sense.
Collections:
This can be based on customer requirements but the collections are generally desktop and server collections (rather than collections per product). Additionally larger customer sometimes want collections per Business Divisions.
There are ALWAYS pre-production and production collections.
Software Update Goups:
The first thing I do when I'm implementing a solution for a new customer is to create a "line-in-the sand".
There are then three phases to the process:
A typical strategy may include the following SUGs:
Desktop
Windows 7 SUG
Windows 8 & 8.1 SUG
All Office updates SUG
Server
Windows 2003 SUG
Windows 2008 & 2008R2 SUG
Windows 2012 & Windows 2012R2 SUG
As we have drawn a "line-in-the-sand" these update groups are static and will never change. The desktop SUGs are then deployed to the desktop collections (pre-production and production) and ditto for the servers (see below for deadlines and maintenance windows). These deployments remain in place indefinitely (even after the updates have been installed). In this way new desktops and servers that are added to the environment can be fully patched very quickly.
2. A Desktop Automatic Deployment Rule (ADR) downloads all desktop updates released in the last month and deploys them to the pre-production desktop collection.
A Server Automatic Deployment Rule (ADR) downloads all server updates released in the last month and deploys them to the pre-production desktop collection.
I schedule the ADRs to run on the 3rd Sunday of every month. As you will know Microsoft normally release updates on the 2nd Tuesday of every month. I delay my ADRs by almost a week to allow Microsoft to withdraw any updates that may have caused problems in customer environments. Each ADR is configured to create a new SUG each month and to deploy with a deadline of 3 days in the future (the newly created SUG has to be renamed to something sensible). After a period of pre-production testing the SUGs are then deployed to production.
3. Annual Maintenance: At the end of each year the 12 monthly SUGs are consolidated into an annual SUG - and the process starts again.
Deadlines and Maintenance Windows:
I do not use maintenance windows for desktops (unless under specific circumstances). When I deploy SUGs to desktop collections I normally schedule the deadline to be 3 or 4 days in the future (and show all notifications). I find that the default notification and restart settings are more than suitable.
Servers require maintenance windows. It could be that you split your server estate into multiple collections so that you can define different maintenance windows. This structure will always be driven by customer requirements.
Out-of-Band updates:
Microsoft sometimes release very critical updates out of band (ie not on patch Tuesday). I create an Out-of-Band SUG which is deployed to each pre-production and production collection. The deployment deadline is in the past so that the updates are installed almost immediately. Server restarts will be controlled by the maintenance windows.
Other items worth a mention:
There is no absolutely correct way to implement a software updates strategy in your organization. Each organization is different and the correct way is the way that works for you. However, after several attempts at trying different approaches, I've decided on a method that delivers a robust solution and is easy to understand and manage. I've included some details below. I hope it makes sense.
Collections:
This can be based on customer requirements but the collections are generally desktop and server collections (rather than collections per product). Additionally larger customer sometimes want collections per Business Divisions.
There are ALWAYS pre-production and production collections.
Software Update Goups:
The first thing I do when I'm implementing a solution for a new customer is to create a "line-in-the sand".
There are then three phases to the process:
- Updates released prior to that point-in-time (eg December 2014) are regarded as historical updates.
- Monthly patch cycles afterwards are regarded as BAU (Business as Usual).
- Annual maintenance of Software Update Groups
A typical strategy may include the following SUGs:
Desktop
Windows 7 SUG
Windows 8 & 8.1 SUG
All Office updates SUG
Server
Windows 2003 SUG
Windows 2008 & 2008R2 SUG
Windows 2012 & Windows 2012R2 SUG
As we have drawn a "line-in-the-sand" these update groups are static and will never change. The desktop SUGs are then deployed to the desktop collections (pre-production and production) and ditto for the servers (see below for deadlines and maintenance windows). These deployments remain in place indefinitely (even after the updates have been installed). In this way new desktops and servers that are added to the environment can be fully patched very quickly.
2. A Desktop Automatic Deployment Rule (ADR) downloads all desktop updates released in the last month and deploys them to the pre-production desktop collection.
A Server Automatic Deployment Rule (ADR) downloads all server updates released in the last month and deploys them to the pre-production desktop collection.
I schedule the ADRs to run on the 3rd Sunday of every month. As you will know Microsoft normally release updates on the 2nd Tuesday of every month. I delay my ADRs by almost a week to allow Microsoft to withdraw any updates that may have caused problems in customer environments. Each ADR is configured to create a new SUG each month and to deploy with a deadline of 3 days in the future (the newly created SUG has to be renamed to something sensible). After a period of pre-production testing the SUGs are then deployed to production.
3. Annual Maintenance: At the end of each year the 12 monthly SUGs are consolidated into an annual SUG - and the process starts again.
Deadlines and Maintenance Windows:
I do not use maintenance windows for desktops (unless under specific circumstances). When I deploy SUGs to desktop collections I normally schedule the deadline to be 3 or 4 days in the future (and show all notifications). I find that the default notification and restart settings are more than suitable.
Servers require maintenance windows. It could be that you split your server estate into multiple collections so that you can define different maintenance windows. This structure will always be driven by customer requirements.
Out-of-Band updates:
Microsoft sometimes release very critical updates out of band (ie not on patch Tuesday). I create an Out-of-Band SUG which is deployed to each pre-production and production collection. The deployment deadline is in the past so that the updates are installed almost immediately. Server restarts will be controlled by the maintenance windows.
Other items worth a mention:
- Don't choose all products in Software Update properties (unless, of course, you need them all - which is doubtful).
- It's quite valid to deploy a Windows 2012 Server update to a Windows 2008 Server for example. The update will not be downloaded or installed and will not create any issue.
- SUG deployments should remain in place. Don't remove them.
- Note that you can use a single deployment package for all updates (the 1000 update rule only applies to SUGs).
- If you get into the habit of configuring this solution with PowerShell you will be able to re-create it quickly time and time again.
Subscribe to:
Posts (Atom)