none
Bug: RemoteApp in Server 2016 sets C:\windows\system32 as "current directory" no matter where the app is stored

    Question

  • Hi

    All applications I publish for RemoteApp on Windows Server 2016 gets "Current directory" set to "C:\Windows\system32\", no matter where I have the application (only tried with applications stored on C:\ fyi)

    This is the environment-settings all applications I've published on a Server 2016 gets (besides the command line ofc).

    My current solution is to use a cmd-script to enter the correct directory and then start it and just publish the .cmd-script.

    Parent PID: 10376
    Command line: "C:\notepad.exe" 
    Current directory: C:\Windows\system32\
    Environment:
    ALLUSERSPROFILE=C:\ProgramData
    APPDATA=C:\Users\Administratör\AppData\Roaming
    CLIENTNAME=SERVER
    CommonProgramFiles=C:\Program Files\Common Files
    CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
    CommonProgramW6432=C:\Program Files\Common Files
    COMPUTERNAME=SERVER
    ComSpec=C:\Windows\system32\cmd.exe
    HOMEDRIVE=C:
    HOMEPATH=\Users\Administratör
    LOCALAPPDATA=C:\Users\Administratör\AppData\Local
    LOGONSERVER=\\SERVER
    NUMBER_OF_PROCESSORS=4
    OS=Windows_NT
    Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Users\Administratör\AppData\Local\Microsoft\WindowsApps;
    PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
    PROCESSOR_ARCHITECTURE=AMD64
    PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 94 Stepping 3, GenuineIntel
    PROCESSOR_LEVEL=6
    PROCESSOR_REVISION=5e03
    ProgramData=C:\ProgramData
    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files
    PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\PowerShell\Modules\
    PUBLIC=C:\Users\Public
    SESSIONNAME=RDP-Tcp#77
    SystemDrive=C:
    SystemRoot=C:\Windows
    TEMP=C:\Users\ADMINI~1.WIN\AppData\Local\Temp\5
    TMP=C:\Users\ADMINI~1.WIN\AppData\Local\Temp\5
    USERDNSDOMAIN=SERVER.LOCAL
    USERDOMAIN=SERVER
    USERDOMAIN_ROAMINGPROFILE=SERVER
    USERNAME=administratör
    USERPROFILE=C:\Users\Administratör
    windir=C:\Windows


    Friday, January 13, 2017 7:56 AM

All replies

  • Hi

    All applications I publish for RemoteApp on Windows Server 2016 gets "Current directory" set to "C:\Windows\system32\", no matter where I have the application (only tried with applications stored on C:\ fyi)

    This is the environment-settings all applications I've published on a Server 2016 gets (besides the command line ofc).


    Hi Patrik,

    By current directory, do you mean working directory?

    What's the specific Operating System of RDS server and were RemoteApp programs published via RDS Deployment within Server Manager?

    Best Regards,

    Amy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, January 16, 2017 5:04 AM
    Moderator
  • Hi Amy

    All of the lines below my previous message is from Process Monitor when the application started up, "Current Directory" is what Process Monitor (Windows Sysinternals) refers "Working Directory" as.

    The server is a Windows Server 2016 Standard, the apps where deployed through RDS Deployment within Server Manager as you guessed.

    Monday, January 16, 2017 2:08 PM
  • I think I had the same on our new 2016  environment. What I did was a home made workaround.

    I created a "appname.bat" and launched the application from there. That solved it for us.

    Not the cleanest workaround but the .BAT file launches so fast the user doesn't see it.

    Tuesday, January 17, 2017 7:52 AM
  • That's exactly what I did as well (which I mentioned in my original post too :)), but it's an ugly solution and shouldn't be needed in the first place so I hope this gets fixed soon.

    Friday, January 20, 2017 7:23 AM
  • That's exactly what I did as well (which I mentioned in my original post too :)), but it's an ugly solution and shouldn't be needed in the first place so I hope this gets fixed soon.

    Sorry about that. Just read the topic and answered what we did.

    Can say that the same software works on server 2012R2 but we need the BAT file on server 2016.

    I recon this is some sort of a bug, boy have I stumbled on lots of them on Server 2016. Almost unusable.

    Reminds me of Server 2012 where they left out "Shadow users" on  Remote desktop and add it again to 2012R2 a year later. So I think we can look to the horizon for 2016R2 where everything is fixed.

    Monday, January 23, 2017 8:41 AM
  • Hi,

    As a workaround I suggest you publish applications that require a specific CurrentDirectory using a shortcut file (.lnk) instead of the exe or cmd script.  For example, say you have an application installed in C:\MyApp on your RDSH servers, and you want it to have C:\MyApp\ as the current directory.  You would create a shortcut with C:\MyApp\ in the Start in box as appropriate, and then use commands similar to below in an administrator PowerShell prompt on your broker:

     
    Import-Module RemoteDesktop
    New-RDRemoteApp -CollectionName "MyCollection" -DisplayName "MyApp" -FilePath "C:\MyApp\MyApp.lnk" -ConnectionBroker "MyBroker" -IconPath "C:\MyApp\MyApp.exe"
     

    Please note that the shortcut (.lnk file) needs to be on all RDSH servers in the collection.  It may be easier to see the correct .lnk file name (to use as part of above ps command) from a command prompt using dir command.

    Thanks.

    -TP

    Monday, January 23, 2017 3:17 PM
    Moderator
  • Hi,

    Please remember to mark helpful reply as answer, which would be very efficient for other forum community members to find useful information.

    Best Regards,

    Amy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, January 31, 2017 12:43 PM
    Moderator
  • Hi, and sorry for my late response to this.

    Since the solution provided isn't any better then the one I've already come up (and described in the initial post) I didn't really see it necessary, my wish with this post wasn't really to find another solution but for this to get forwarded to the devs so they can fix this bug.

    Thank you for your time.

    Tuesday, April 11, 2017 12:18 PM
  • Hi, and sorry for my late response to this.

    Since the solution provided isn't any better then the one I've already come up (and described in the initial post) I didn't really see it necessary, my wish with this post wasn't really to find another solution but for this to get forwarded to the devs so they can fix this bug.

    Thank you for your time.

    Hi Patrik,

    The workaround I gave is superior to the cmd script method you mentioned in your initial post in that it is transparent to the end user.

    -TP

    Tuesday, April 11, 2017 12:24 PM
    Moderator
  • hi!

    none of these tricks fix the issue. common user cannot write to system directories and although the app (no matter how launched - from desktop remote session or as remoteapp) can start it fails on saving state or any write attempt with relative path because it tries to write to system32 subtree.

    any suggestions?

    Tuesday, May 30, 2017 7:01 AM