It seems like there are features I'd like to see when streaming from a network share that you don't get when streaming from the web server and vice versa. Neither side seems to have all the features.
What I'm wondering is...
1)
Is there any way to specify where to put the Sandbox and Cache when streaming from the web server?
I know you can use SpoonReg.exe to specify these things but I see no mention of using it in conjunction with the web streaming. We wanted to deliver apps via shortcuts to these web apps as such...
SpoonPlay.exe /config=http://appstreaming.myserver.gisd/config/MyApp.xml
Anybody know how to manipulate their default sandbox and cache locations? We have (and will have more) machines with volatile user profiles. So I can't have the sandboxes and cache having to be completely rebuilt every time the user gets on.
2)
Is it possible to profile the separate parts of a jukeboxed app or do you have to build it each time with a different auto start exe and then just collect all the profiles that way? I tried creating a shortcut to call a different part of the ZAV but it ignores the commands in the shortcut when profiling and just launches whatever the auto start exe was. Or is profiling all of them even necessary?
3)
We have tested a ZAV of Photoshop CS5 (only photoshop and not the entire CS5 suite) on the web server. We see several issues...
1. It actually takes longer than a normal ZAV to launch. We thought one of the main benefits to using streaming was faster start time. We aren't seeing it. It isn't network speed because the buffering and prefetch fly by but the launch time takes forever. Around 1.5-2 minutes. Even after the sandbox has been built and the cache seems to be fully built.
2. When you close the program SpoonPlay.exe continues to run in the background for what seems like 5-10 minutes. It seems to use anywhere from 0-25% of the CPU and the memory usage fluctuates up to around 250mb. During this time you can't launch the program again. What is taking so long for that SpoonPlay.exe to close? We can't expect users to have to wait 5-10 minutes if they decide to close the program and then reopen it.
Anyway I realize we may be missing something so I was hoping somebody had an idea.
Thanks,
Ryan
What I'm wondering is...
1)
Is there any way to specify where to put the Sandbox and Cache when streaming from the web server?
I know you can use SpoonReg.exe to specify these things but I see no mention of using it in conjunction with the web streaming. We wanted to deliver apps via shortcuts to these web apps as such...
SpoonPlay.exe /config=http://appstreaming.myserver.gisd/config/MyApp.xml
Anybody know how to manipulate their default sandbox and cache locations? We have (and will have more) machines with volatile user profiles. So I can't have the sandboxes and cache having to be completely rebuilt every time the user gets on.
2)
Is it possible to profile the separate parts of a jukeboxed app or do you have to build it each time with a different auto start exe and then just collect all the profiles that way? I tried creating a shortcut to call a different part of the ZAV but it ignores the commands in the shortcut when profiling and just launches whatever the auto start exe was. Or is profiling all of them even necessary?
3)
We have tested a ZAV of Photoshop CS5 (only photoshop and not the entire CS5 suite) on the web server. We see several issues...
1. It actually takes longer than a normal ZAV to launch. We thought one of the main benefits to using streaming was faster start time. We aren't seeing it. It isn't network speed because the buffering and prefetch fly by but the launch time takes forever. Around 1.5-2 minutes. Even after the sandbox has been built and the cache seems to be fully built.
2. When you close the program SpoonPlay.exe continues to run in the background for what seems like 5-10 minutes. It seems to use anywhere from 0-25% of the CPU and the memory usage fluctuates up to around 250mb. During this time you can't launch the program again. What is taking so long for that SpoonPlay.exe to close? We can't expect users to have to wait 5-10 minutes if they decide to close the program and then reopen it.
Anyway I realize we may be missing something so I was hoping somebody had an idea.
Thanks,
Ryan