Can a "User" based Global Property like Primary Device be used when deploying applications to devices?

No, that doesn't make sense. By definition, when deploying to a device, the user is not part of the equation since any user could install the application from software center and software center is in no way user specific.

Cool, thanks Jason.

I was not sure as there are two ways to look at UDA. A User has a defined primary device (or devices) but also a device has a defined Primary User. I was not sure if the ConfigMgr client would look up what user was logged on for a Deployment that was marked as "Available" and "Only install when logged on". Given a user is logged on under these conditions the ConfigMgr client could potentially determine who was logged on and do a UDA lookup.

Thanks Eswar and Jason.

Hi All,

I am currently troubleshooting an application installation. I have a single Application with 3 Deployment Types:

1. Windows installer (To be installed on a Primary Device only) (Priority 1)
2. App-V installer (To be installed on non-Primary devices only) (Priority 2)

I have defined these requirements on each of the deployment types however the Windows installer package is being installed on non-primary devices. I am only working with 2 PCs and one use account. The User has one Primary Device only.

I have reviewed http://blogs.technet.com/b/manageabilityguys/archive/2013/10/01/configmgr-2012-tracking-application-model-installations-on-clients.aspx but I cannot find any reference to where application requirements are evaluated and logged?

Any help would  be great.

C

Hi Again,

OK, based on what I can now see it is the AppIntentEval.log that provides some details.

ScopeId_1E9BB7E7-492A-4224-A214-E85865AEB1EC/DeploymentType_b0a48a40-b15d-45e7-b86e-1ef3636a40ac/1 :- Current State = NotInstalled, Applicability = NotApplicable, ResolvedState = None, ConfigureState = NotNeeded, Title = TTWin_3_9_10 - Microsoft Application Virtualization 5 AppIntentEval 16/06/15 10:47:25 AM 3324 (0x0CFC)

ScopeId_1E9BB7E7-492A-4224-A214-E85865AEB1EC/DeploymentType_d4d4467b-49e1-4020-a510-c26f53c421eb/2 :- Current State = NotInstalled, Applicability = Applicable, ResolvedState = Available, ConfigureState = NotNeeded, Title = TTWin3.9 - Windows Installer (*.msi file) AppIntentEval 16/06/15 10:47:25 AM 3324 (0x0CFC)

The Log file shows that the MSI is application, the App-V version is not. My new question is there anyway to determine the results of each requirement?

Thanks,

The results of any applicable(needed) applications are tracked from appenforce.log if the application is success or failed ,have a look at indepth about application deployment http://blogs.msdn.com/b/steverac/archive/2012/11/18/configmgr-2012-application-model-internals-part-ii-client-side-deployment.aspx

Hi Eswar,

Thanks for the reply. I have gone though the article using my situation as a reference. Unfortunately I am not seeing the same activity in the logs as the article describes. Given I am moving SCCM 2007 and am still getting familiar with 2012 it could be that I am not using the Primary Device property correctly.

This thread is similar to what I am doing...

https://social.technet.microsoft.com/Forums/en-US/4fa85d15-678d-4f1a-bb49-bfb58ac2c0a7/appv-application-required-deployment-for-primary-device-machine-available-for-other-machines?forum=configmanagerapps

Going back to my example I have:

1. One application with two deployment types (MSI and App-V)
2. I am deploying the application to Devices as "Available"
3. I want to ensure the MSI installation occurs on Primary Devices Only and the App-V version is installed on non-Primary devices.
4. Currently the MSI Deployment type has "Operating System = Windows 7 x64 (all) and Primary Device = True" requirements
5. Currently the App-V Deployment type has "Operating System = Windows 7 x64 (all) and Primary Device = False" requirements

After some more testing I noticed that if I remove the "Primary Device = False" requirement on the App-V deployment type the AppIntentEval.log reports "Applicability = Applicable". That is what I would expect. However The MSI Applicability is also "Applicable" even through the device I am logged onto is not the Primary Device.

Based on this I can only assume that I have an issue with determining the primary device. The "Primary User" for each Device is correct with the SCCM database however and The "My Device" section of the Application Catalogue also reflects the correct information.

Can a "User" based Global Property like Primary Device be used when deploying applications to devices?

So, based upon https://technet.microsoft.com/en-au/library/gg699365.aspx?f=255&MSPPError=-2147217396 it implies that UDA is to facilitate the targeting of applications to users rather than devices. I am just not sure if this is enforced by the SCCM client.

Ultimately what got me to this point relates to the scenario I have mentioned above and how to effectively manage Redirected Folders such as the Start Menu and Desktop.

If I have my Primary Device with an MSI installed application. Via policy the Start Menu and Desktop folders are redirected. The MSI creates a Program Group, some program shortcuts and a desktop icon. All of these are created within the Common/All Users profile. At the same time I log on to a second (non-Primary) device and then install an App-V version of the same application. The App-V version (published to users) also creates a Program Group, shortcuts and a desktop shortcut. With redirected folders these links overwrite the links on the primary device.

I was trying to deliver the App-V version of the application to devices so that the App-V shortcuts and desktop icon would also be created under the All Users/Common Desktop and Start Menu. This would avoid the issue described above. It is when I targeted the App-V application at devices that I hit the UDA issue.

Now, I can just disable Start Menu and Desktop redirection but that is a technical compromise which I am excluding for now.

Any advice would be