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.
Friday, 28 November 2014
One million pageviews in first 21 months
Back to ConfigMgr main menu
I started this blog in February 2013 and I've really enjoyed sharing tips and ideas with the community. I've also received overwhelming support and I really appreciate it. I'm amazed to see that there have been over one million pageviews in the first 21 months.
I will continue to post blogs about subjects that interest me. I hope they will be of interest to others. My focus for 2015 will be on Microsoft EMS and Azure.
Thanks again,
Gerry
I started this blog in February 2013 and I've really enjoyed sharing tips and ideas with the community. I've also received overwhelming support and I really appreciate it. I'm amazed to see that there have been over one million pageviews in the first 21 months.
I will continue to post blogs about subjects that interest me. I hope they will be of interest to others. My focus for 2015 will be on Microsoft EMS and Azure.
Thanks again,
Gerry
Thursday, 27 November 2014
Intermittent issue with Direct Access connection
I had this tricky problem on a customer site recently. Direct Access (Windows Server 2012 R2) worked perfectly most of the time but intermittently the Workplace Connection would just remain "Connecting" indefinitely. The logs showed that the connection failed with the following error:
0x274c
CouldNotConnectToDirectAccessServer
This error was too generic to be useful and there was no pattern to this bizarre behaviour.
I eventually found the problem. ISATAP had not been removed from the Global Query Blocklist on one of the DNS servers.
Note that this is not an automatic process. It has to be done manually on all DNS servers. I removed ISATAP and restarted the DNS Server service.
Problem solved.
0x274c
CouldNotConnectToDirectAccessServer
This error was too generic to be useful and there was no pattern to this bizarre behaviour.
I eventually found the problem. ISATAP had not been removed from the Global Query Blocklist on one of the DNS servers.
Note that this is not an automatic process. It has to be done manually on all DNS servers. I removed ISATAP and restarted the DNS Server service.
Problem solved.
Monday, 17 November 2014
Linux Management with ConfigMgr - Issues I've encountered
Back to ConfigMgr main menu
Back to Linux menu
I encountered a couple of issues while carrying out this work. I hope that they can save you some troubleshooting time.
1. Extracting client installation files.
The "ConfigMgr Clients for Linux.exe" file is 62MB.
This file extracts into the client installation files that you require.
You must extract this file using an x64 OS.
You will receive this error if you try to extract using x86 OS.
2. Software Distribution.
I encountered error 10006 while deploying an RPM package to a Linux Server (I was trying to deploy Teamviewer for Linux). After quite a lot of troubleshooting I finally tried to manually install the software on the server and found that the installation failed due to missing prerequisite files. Clearly my ConfigMgr deployment would never have worked and it's very difficult to determine the cause from log files.
Back to Linux menu
I encountered a couple of issues while carrying out this work. I hope that they can save you some troubleshooting time.
1. Extracting client installation files.
The "ConfigMgr Clients for Linux.exe" file is 62MB.
This file extracts into the client installation files that you require.
You will receive this error if you try to extract using x86 OS.
2. Software Distribution.
I encountered error 10006 while deploying an RPM package to a Linux Server (I was trying to deploy Teamviewer for Linux). After quite a lot of troubleshooting I finally tried to manually install the software on the server and found that the installation failed due to missing prerequisite files. Clearly my ConfigMgr deployment would never have worked and it's very difficult to determine the cause from log files.
Linux client - software distribution and patching
Back to ConfigMgr main menu
Back to Linux menu
Previously we installed the ConfigMgr client and the Linux server is now managed and reporting normally. We are now ready to deploy software to the server. No further configuration is necessary. We should be aware of the following:
(Tip - carry out a manual test installation of the RPM package before you deploy it in production. If the RPM has some missing prerequisites the deployment will fail with error 10006. It's hard to troubleshoot this but easy to identify in a test.)
We use the traditional package/program for this patching/software distribution.
Right click Packages and choose to "Create Package".
Name the package and configure the location of the source files.
Choose "Standard Program".
The syntax of an RPM installation command is as follows:
rpm -i filename.rpm
Click Next to finish.
Don't forget to distribute the content and then you can deploy the package.
Choose a collection that contains the Linux server.
You MUST choose "Required".
You MUST choose "Download content from Distribution Point and run locally".
Carry out a quick test on the Linux server to verify that the patch is not already installed.
rpm -qa | grep ppl-0.10.2-11.el6.x86_64
(note that the file extension .rpm is not included in this command).
/opt/microsoft/configmgr/bin/ccmexec -rs policy
Test again
rpm -qa | grep ppl-0.10.2-11.el6.x86_64
Patch is now present.
Successful deployment.
Back to Linux menu
Previously we installed the ConfigMgr client and the Linux server is now managed and reporting normally. We are now ready to deploy software to the server. No further configuration is necessary. We should be aware of the following:
- The ConfigMgr client will use the Network Access account to connect to the Distribution Point and download the package to the ConfigMgr cache on the Linux server.
- You must configure the following option for your deployment - "Download content from Distribution Point and run locally".
- You must configure the deployment as "Required". "Available" is not supported for Linux servers.
- You do not need to modify the permissions of an RPM file to allow it to be executed.
(Tip - carry out a manual test installation of the RPM package before you deploy it in production. If the RPM has some missing prerequisites the deployment will fail with error 10006. It's hard to troubleshoot this but easy to identify in a test.)
We use the traditional package/program for this patching/software distribution.
Right click Packages and choose to "Create Package".
Name the package and configure the location of the source files.
Choose "Standard Program".
The syntax of an RPM installation command is as follows:
rpm -i filename.rpm
Click Next to finish.
Don't forget to distribute the content and then you can deploy the package.
Choose a collection that contains the Linux server.
You MUST choose "Required".
You MUST choose "Download content from Distribution Point and run locally".
Carry out a quick test on the Linux server to verify that the patch is not already installed.
rpm -qa | grep ppl-0.10.2-11.el6.x86_64
(note that the file extension .rpm is not included in this command).
Request Machine
Policy
/opt/microsoft/configmgr/bin/ccmexec -rs policy
Test again
rpm -qa | grep ppl-0.10.2-11.el6.x86_64
Patch is now present.
Successful deployment.
Subscribe to:
Posts (Atom)