Thursday, 18 October 2018

SCCM task sequence failing on app installations (error 80070652)

I had this problem on a customer site today and I hadn't seen it before. A task sequence failed intermittently (but often) on two particular applications (one was an SCCM application and the other a package/program). These apps had nothing in common, besides being consecutive in the task sequence.

The SMSTS.log file told me that that installations failed because:

Another installation is already in progress. complete that installation before proceeding with this install. (error: 80070652; source: windows)

I really didn't understand this as everything else looked ok in the log file. Palo Alto VPN client and MBAM were the two apps that regularly failed without any obvious reason. The only thing I could see that they had in common was that they closely followed McAfee VirusScan in the task sequence. Like many other ConfigMgr-related issues, could McAfee be the problem?

I looked at the application event log and sure enough I found McAfee-related activity long after it had returned an exit code of 0, thus allowing the task sequence to continue. Further installations were not possible as McAfee was still doing it's thing and the task sequence just failed.

To test my theory I just moved the McAfee installation to the end of the task sequence. That did it and the task sequences all compete successfully now. Happy days.

Guess what? I just left it there where it belongs :)

I hope this is helpful to anyone else who encounters this behaviour. Until next time...

Monday, 24 September 2018

Intune - sidecar for Win32 apps revealed

Traditionally it has not been easy to deploy applications to Windows 10 devices managed by Intune. There is a great solution for deploying Office 365 ProPlus. Also, it's always been easy to deploy single file MSIs and that's great. However how many apps do we admins get to deploy that are packaged very nicely by the vendor into single MSI files? Not many I'd say. Usually we get a .exe file or in fact the installation files contain multiple folder and files.

So what have our choices been to deal with this? 
  • Repackage EXEs & MSIs with multiple files to a single file MSI using 3rd party tools (e.g. Flexera Admin Studio) - can be complex.
  • Convert apps to .appx using the desktop bridge - the desktop app converter is Microsoft’s utility to do this and it's is not a straightforward tool to use.
  • Deploy apps using PowerShell scripts - this is very powerful and uses the Intune management extension in conjunction with Azure blob storage.
The Intune management extension (codename sidecar) supplements the native Windows 10 MDM capabilities. So, how does it work? How do we get the management extension on to the devices?

Well, it’s just an MSI itself and we’ve been able deploy MSIs for quite some time. If a PowerShell script is assigned to a user and the Intune management extension is not already installed on a device, it will be pushed down to the device automatically by Intune. You’ll be able to see it as a service and in Programs and Features. You'll also get a new folder structure and access to log files (IntuneManagementExtension.log for example)

The agent then checks for policy every 60 minutes. Remember the device itself only syncs every 8 hours? You can force the device to sync immediately by restarting the “Microsoft Intune Management Extension” service.

That sounds really cool, doesn't it and it is really cool. Wouldn't it be great if sidecar could be used natively to deploy .exe files without the need for scripts and independent Azure storage. Well Microsoft have been listening.

This has now been announced at Ignite so we can finally talk about it. The Intune management extension now supports native Win32 app deployment. This is made possible by the introduction of a new file extension that can be uploaded to Intune - the .intunewin file.

I've been able to get an advance preview of this so let's walk through the process

  • Windows 10 version 1607 and later
  • Windows 10 edition (Enterprise, Pro, Edu, IOT Core, IOT Enterprise Core)
  • Device must be Azure AD joined and Intune enrolled
Prepare the app

Microsoft have developed a new tool, the Microsoft Intune Win32 App Packaging Tool, to pre-process Win32 apps. The packaging tool converts application installation files into the .intunewin format. The packaging tool also detects some of the attributes required by Intune to determine the application installation state. After you use this tool on the app installer folder, you will be able to create a Win32 app in the Intune console. I've used it and it works really well.

You can download the tool from GitHub

You will also find the command-line parameters available for the tool.

Copy the app to a source folder. I've 7Zip for this test and it's small and quick, and it's an exe file. We've not been able to deal with this easily up to now.

Intune Win32 App Packaging Tool is a command line tool. Browse to the location and launch the tool. Specify the source location of the app (7Zip for me).

Specify the location for the output file. The tool executes and finally produces the .intunewin file....

...which you'll find in the output folder.

Upload the app

Now we can add the app in Intune, select the new file type available (at the bottom). This is not yet generally available.

Browse to the .intunewin app in the App package file pane.

Configure the app information.

Configure the program details. Note that you must know the silent installation (and uninstall) parameters.

Configure the requirements. You must enter OS architecture and minimum OS.

Configure the detection rule. We know all about this from ConfigMgr. We can choose MSI product code, presence of file or folder or registry value. I'm using the file-based option.

This is our detection rule.

I've accept the default return codes.

The app is uploaded to Intune and created.

Assign the app to an Azure AD group as normal.

Behavior on device.

My test device has already been used for testing of app deployment using PowerShell script. Therefore the Intune management extension is already installed. I've restarted the service to get immediate action.

I'm notified that software changes are required. The IntuneManagementExtension log file also tells me that a Win32App is about to be installed.

Installation is finished.

App is installed.

This is a huge step forward for software deployment to Windows 10 devices with Microsoft Intune. It is now much easier to deploy business Windows apps to MDM-enrolled devices. This can simplify your shift to the modern desktop. You don't have to change of course. If you're currently using ConfigMgr to deploy apps then keep doing that, as it works really well. If you want to go to modern desktop this new feature will remove a major roadblock.

I hope it helps you. 

Until next time........

Monday, 3 September 2018

Intune - improvements to Office 365 ProPlus deployment

Simplified Office 365 ProPlus deployment has been a very popular feature of Microsoft Intune for quite some time. In the last few weeks there have been two improvements that will be very useful.

1. Now we can edit Office 365 ProPlus app deployments if we want to make changes, remove an app or change the channel, for example. Previously we had to delete the deployment and add a new one which was a real pain.

Editing the Office 365 ProPlus deployment

2. We also have greater control as we can now choose the specific version of Office 365 ProPlus to install. We don't have to accept the latest version any more.

Choose App Suite Settings in the properties of the deployment. In the section "Version to install on end user devices" choose Specific.

You now must choose a version.

There are many to choose from and the choices will change as the list is continually updated. 

Why is this significant? In my opinion it's very important to be in control of the version of software that you deploy to your estate. You need time to test your line of business apps, add-ins and macros so perhaps you don't want to be deploying the latest version as soon as it is published.

To me these are two very useful features. Until next time......

Wednesday, 1 August 2018

ConfigMgr - PXE without WDS

ConfigMgr Current Branch 1806 will shortly be released. One of the most eagerly awaited features (my favourite) is that we can now enable PXE on our DPs without Windows Deployment Services (WDS). This is an enormous step forward as it will save customers money. I have customers with many PXE-enabled DPs throughout the world. That's a lot of server licensing. Previously a server OS was required simply for WDS. Now we can use a desktop operating system for the DP and enable it to use a lightweight PXE responder. That will save customers a lot of money. Let's have a look at that.

This is the traditional server DP with WDS.

Remember the RemoteInstall folder.

Now we have a new checkbox when creating a DP - Enable a PXE responder without WDS

We're told that selecting this option will disable WDS on existing DPs. Also we can see that the new service does not support multicast. I can live with that.

Understandably Multicast options are now greyed out in the wizard.

This is what the folder structure looks like on a PXE-enabled Windows 7 DP, no RemoteInstall folder. Wow.

This is the new lightweight ConfigMgr PXE Responder Service. Who needs WDS?

We can see the path to the executable file sccmpxe.exe.

This is where the SCCM PXE files are located.

I can PXE boot as normal. See the way we're told that SCCM PXE now provides this service (not WDS).

This is a really cool feature and will save many customers a lot of money on server licensing. It's a good enough reason alone to upgrade to ConfigMgr Current Branch 1806. 

I hope this was useful. Until next time....

Friday, 20 July 2018

Intune - Block app access based on unapproved device vendors and models

This is one the most recent new features to be published by the Intune team. We can now specify a list of Android manufacturers and iOS models and choose an action to be performed on the devices specified in the list. At the moment we have a choice of two actions:
  1. Block devices that are not specified from accessing an app
  2. Perform a selective wipe of corporate data on devices that are not specified
This sounded really cool to me so I tested to see if this was easy to configure. It is. It's as easy as typing a list of Android manufacturers and iOS models separated by a semicolon.

In Microsoft Intune, select Mobile apps > App protection policies and select Add a policy.

Enter a name and choose a platform (Android in this case). Select your required apps and configure your required settings as normal.

Now, in the Settings page, scroll to the bottom to the Access Actions settings.

You'll find an existing list of settings, values and actions.

Click on the drop down arrow to reveal some additional choices. Select Device manufacturer(s).

A new line is added. We now must configure the values and action.

Enter your required values. As soon as you type a semicolon you are prompted for another value. The Microsoft documentation has a warning about this. 

"On end-user devices, the Intune client will take action based on a simple matching of the strings specified in the Intune blade for Application Protection Policies. This depends entirely on the value that the device reports. As such, the IT administrator is encouraged to ensure that the intended behavior is accurate. This can be accomplished by testing this setting based on a variety of device manufacturers and models targeted to a small user group".

In other words Intune will not check that what you've typed is accurate. It will only recognize it as a series of strings.

Next, choose your required action. I want to block access to my app for all Android devices except Samsung and HTC devices. Click OK to create the policy as normal.

It's very similar for iOS devices except that you choose Device models.

There are a couple of additional considerations:
  1. On iOS devices, this feature requires the participation of applications (such as WXP, Outlook, Managed Browser, Yammer) to integrate the Intune APP SDK for this feature to be enforced with the targeted applications.
  2. On Android, this feature requires the latest Company Portal.
I think this is a very useful feature and I hope it helps you. Until next time......