Occasionally in my series of articles I want to address some tips around troubleshooting various issues that may crop up related to our product line. In this first of that type of post, I’ll address a recent example I saw internally with an engineer doing some work in a lab environment. I thought this might be interesting for our 1E Shopping customers should you uncover a similar scenario. This article assumes a complete understanding of the Shopping product, its architecture and component parts, as well as our integration with ConfigManager
A colleague recently ran into an unusual issue on a test machine in a Hyper-V lab using 1E Shopping and its integration with Configuration Manager 2012 software distribution. As you likely know, when a title is shopped for (an order is placed) Shopping automates the creation and execution of the ConfigManager components to deploy the requested software once approved, if required; or, it is deployed immediately otherwise.
The Problem
When deploying the software manually using SCCM it works perfectly fine (manually creating the package, then the target collection and then the deployment). When doing exactly the same thing with the same package via Shopping it fails with following error:
An error occurred while preparing to run the program for deployment "PRI20014" ("PRI00007" – "Per-user attended"). Additional program proper
ties:
Command line: msiexec.exe ALLUSERS="" /m MSIYRQRH /i "Winzip.msi"
Working directory:
Drive letter (? = any):
Possible cause: This message most commonly occurs when the program's command-line executable file could not be found or when a required drive letter connection to a distribution point could not be established.
Solution: Check each of the items listed above
The description of the deployment error is shown as “Failed (Bad environment)” in the SCCM deployments section under the Monitoring tab. The collection and deployment is created normally via the Shopping integration process, but for some reason the MSI installer package (which ultimately has to run on the client machine) doesn’t get copied to the local CCMCache location on the client machine from the distribution point. The SCCM primary machine in this lab environment is also the distribution point. I’ve tried multiple options that are available as a probable solution on the internet but to no help. I even created a fresh client machine from scratch to get rid of any old environment related issue but it failed again with same error.
The Environment
This lab environment consisted of a SCCM 2012 SP1 environment with a CAS and a single primary running on separate Server 2012 standard editionx64 servers. Boundaries were configured as 10.10.26.28-10.10.26.61, where the Win7SP1 client was 10.10.26.30. Of course, since this is a Hyper-V lab, the DISTRIBUTION POINT component in the package properties were set automatically assuming a fast network. Below are the properties of the deployment (in SCCM) which was created by Shopping. Here you can see the option for high speed LAN environment and for slow and unreliable network boundary conditions.
Do Not Run Program
Note above that the DP property says “Do not run program” if the client is detected on a slow network.
The Resolution
In this Hyper-V lab the client computer policy refresh (which initiates SCCM deployments) was treating the local network condition as “Slow and unreliable”. As a result, the option set for such a network condition (“Do not run program”, shown above) was coming into play. The policy refresh was therefore not taking any action and the deployment failed every time. This failure was consistent for other client computers as well that were present in the Hyper-V lab. In fact a new VM was created from scratch to eliminate any possibility of a machine specific issue. There was clearly something to do with the lab environment itself. It was unclear if the issue resulted from Hyper-V, SCCM, operating system, networking or something else entirely. When the remote client flags value was changed from 0 (which was being used as the default in this lab) to 3152, both of the deployment options were then set to “Download content from distribution point and run locally”. With this setting, even when the SCCM client evaluated the network as slow and unreliable, it downloaded the content and ran it locally resulting in a successful deployment.
While the package/program itself did not change between the “manual“ deployment test (via native ConfigManager) and using Shopping to do the same thing, the ConfigMgr program deployment itself has.
The Shopping Receiver creates the program’s deployment based upon the values specified by “AdvertFlags” and “RemoteClientFlags”. These values and their meaning are documented here. If you compare the “successful” (manual) deployment object to that created by the Shopping Receiver, you may find an important difference, and one that can be corrected by adjusting the value of one of these two settings in the Shopping.Receiver.exe.config file.
The issue: the default value for the Receiver’s RemoteClientFlags is 2096, which includes bit 5 (interpreted by SCCM as “Do not run the program if there is no local distribution point”). This also happens to be the default value used by native SCCM for deployments created via the console. A typical setting for using Shopping in a lab is to set the RemoteClientFlags setting to 3152, as noted earlier (Bits 4,6,10,11), with Bit 6 enabling “Download the program from the remote distribution point and run locally” for both network options above.
With further investigation, it was also determined that SCCM somehow evaluated the client as being on a “slow and unreliable network” in this Hyper-V environment! Consequently the package would not download at all, returning the error message text as shown above.
Further contributing to this was the fact that the Deployment was set to “run from Distribution Point”, but the package didn’t have the legacy share option enabled (you can’t run a program from a DP unless it has the legacy share option enabled. The package cannot have a working directory of HTTP://).
In Summary

  • If you have defined any remote boundaries or want your clients to use a fallback distribution point, you’ll need to change the RemoteClientFlags setting if you want these clients to install software
  • You can specify the REMOTECLIENTFLAGS property when you install the Shopping, or edit the Shopping.Receiver.exe.config file to modify the setting post-installation.
  • Task sequences also have their own Remote client flag. Add bit 9 to allow your clients to download task sequence content from a remote distribution point.

Acknowledgements
Thanks to Rasik Bihari for raising and documenting this issue; and, to Duane Gardiner of our Professional Services team for the diagnostics and troubleshooting efforts that identified the root cause, its resolution, and assistance drafting this article.