Hi there! Welcome to my blog. My name is Ivan. I am a Dutch IT Professional working as Principal IT Consultant. AppV server supports different options to steam your SFT deployment file. RTSP, RTSPS, FILE, HTTP and HTTPS are the protocols available for the Server URL.
Currently I am evaluating to use the FILE option and store the virtual package on a file share. I am using the RTSP protocol and I am looking to get rid of the AppV steaming servers and only use file shares.
I import my new Jing virtual application on my AppV management server and refreshed my local AppV client to publish the new application.
The icon appeared on the desktop and I opened the shortcut. I immedialty received the following “Application Virtualization Error”.
The operation failed because you do not have sufficient permissions to stream from a file. Report the following error code to your System Administrator.
Error code: 4615186-14902204-0000180B
During the installation AllowIndependentFileStreaming was not set when the AppV client was installed.
To correct this and allow streaming of a SFT file from a FILE share please change the following registry key to 1 and restart “Application Virtualization Client” service.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\AllowIndependentFileStreaming
I used the following script to change my clients and allow the FILE streaming:
reg add HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration /v AllowIndependentFileStreaming /t REG_DWORD /d 1 /f net stop sftlist net start sftlist
Tim Mangan
If you are still publishing from the App-V server, I don’t see the point. RTSP will support disruptions in the streaming process that CIFS will not. Even if you do want to go that way, I would recommend a client ASR (“FILE:\\server\share”) override in the client registry while keeping the OSDs pointing to RTSP (makes it easy to cut over without editing the packages, and to change back). You still need the registry setting you identified at the client. In either case, with file: you still get the app fully cached (whether created with a small FB1 or not), and a form of “active update”. The kicker is that you can’t replace the file on the server without a maintenance window, and is better not to have the _2.sft naming.
If you do get rid of the App-V server completely, then you will also need to disable RequireAuthorizationIfCached setting, and probably set LimitedDisconnection timer to zero (although I am unclear if that last one is truly needed), and possibly add permissions depending on how you get the virtual apps there. Stand-alone client is a great way to go!