locked
File detection method fails. Path contains %Appdata% RRS feed

  • Question

  • Hi

    I need to customize my application deployment on the following sequence:

    1. Install main application (msi)
    2. Copy config file (ibases.v8i) to user directory (%AppData%\1C\1CEStart).

    I create 2 applications:

    1. Main application from msi file
    2. SFX Archive with config file. This application depend from main application and deployed for user and require primary device.

    Second application use file detection like on image

    But this detection not work and deployment fail with . In DCMWmiProvider.log I see next error:

    CAppExecutionLibrary::ExpandEnvironmentVariables: %AppData%\1C\1CEStart\ evaluated to : %AppData%\1C\1CEStart\	FileSystemWMIProvider	18.04.2013 19:39:54	5412 (0x1524)
    CAppExecutionLibrary::ExpandEnvironmentVariables: %WinDir%\System32 evaluated to : C:\Windows\System32	FileSystemWMIProvider	18.04.2013 19:39:54	5412 (0x1524)
    CAppExecutionLibrary::ExpandEnvironmentVariables: %ProgramFiles% evaluated to : C:\Program Files	FileSystemWMIProvider	18.04.2013 19:39:54	5412 (0x1524)
    
    What i need change to use file detection for %AppData% folder
    Friday, April 19, 2013 1:33 PM

All replies

  • Do you have the deployment type set to install as user? Keep in mind that by default the ConfigMgr client runs in the SYSTEM context, not the user context.
    Friday, April 19, 2013 1:59 PM
  • Yes, this deployment type is configured for users.

    Deployment part works and config file copied to destination path.


    Friday, April 19, 2013 2:03 PM
  • If I understand correctly your deployment works but your detection method does not. The reason is that, even though the deployment runs as the user, the detection method does not. That seems to run in the System context (not sure whether this is by design or not). Therefore the detection method will never be able to understand user variables like %AppData% or %userprofile%.


     
    You have to handle this another way. You should amend your deployment to copy a file to shared area (eg Public profile desktop). You can then use C:\Users\Public\Desktop\testfile.txt as your detection method.


     
    This issue has previously been discussed on this forum.


     
    http://social.technet.microsoft.com/Forums/en-US/configmanagerapps/thread/3fd796c4-45f0-42cf-bc3d-bccd6caf73a8/



    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson


    • Edited by Gerry HampsonMVP Wednesday, June 26, 2013 12:09 AM Edited blog address
    Saturday, April 20, 2013 10:52 AM
  • Gerry, thank you for reply.

    You write that detection doesn't works from user, but I think that you mistake. I changed file detection to next Powershell script and detection and deployment works fine

    if (Get-ChildItem ($Env:Appdata + "\1C\1CEStart")|Where-Object {$_.Name -eq "ibases.v8i"}) {
        return 0
    }
    If detection can`t work from user as you write I should get same error with Powershell detection. I didn't find any documentation about possible variables and limitations in File Detection method.
    Monday, April 22, 2013 8:16 AM
  • I haven't personally experienced this issue. I just recall it from last year. Have you read the link

    http://social.technet.microsoft.com/Forums/en-US/configmanagerapps/thread/3fd796c4-45f0-42cf-bc3d-bccd6caf73a8/

    It is exactly the same issue as yours. Perhaps this is not the case in SP1.



    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson


    • Edited by Gerry HampsonMVP Wednesday, June 26, 2013 12:09 AM Edited blog address
    Monday, April 22, 2013 10:52 AM
  • I know this is an old post but if someone finds this try this out:

    If it's an installer that is localted in %APPDATA% there's usually a trace left in the HKCU Path:

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall

    Install the software manually first, then browse to your HKCU location above and see if an entry is left there... This worked great for SCCM detection :)

    
    Tuesday, April 16, 2019 4:51 PM