Tuesday, 9 December 2014

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).

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.

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

Monday, 8 December 2014

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 thatthere 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.

Tuesday, 2 December 2014

Back to ConfigMgr main menuThere 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.

1. It is important to note that there is a hard limit of 1000 updates per software update group (SUG). This makes it impossible to include all historical updates in a single SUG (eg Windows 7 currently has almost 700 updates). In this phase I create Software Update Groups as required.

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

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.

Thursday, 27 November 2014

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.

Monday, 17 November 2014

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 ConfigMgr main menuBack to Linux menuPreviously 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.

RPM (RPM Package Manager) is a popular utility for installing software on Unix-like systems, particularly Red Hat Linux. Download your RPM package to a source folder.(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.