none
New Setup

    Question

  • We evaluated appv about a year ago, we had it working, but didn't have the infrastructure for it at the time.  I am setting up a server again to test it on our new system, and I am running into some problems.  I followed the install guide, and I can publish the default app.  My client machines can see the default app, but can not open it.  Client machines are getting "No connection could be made because the target machine actively refused it".  I checked the clients via telneting into the server on 554, and it worked without a problem.  All the posts online, seem to point to a connectivity problem, but my connectivity does not seem to be the issue.  Windows firewall is disabled on the server...  I'm not sure what else to check.  I edited the defaultapp.osd file to reflect the RTSP, but it seems like I'm getting nowhere.  Please, someone point me in the right direction  :)

    <CODEBASE HREF="RTSP://SERVERNAME.DOMAIN.COM:554/DefaultApp.sft"
    Friday, November 06, 2009 2:44 PM

Answers

  • I have no explanation for this, but the default app started working.  Turned my test machine off, let it sit for a half hour, turned it back on, and now it works.  Makes no sense at all, but I'll take what I can get.
    Thursday, November 19, 2009 3:08 PM

All replies

  • Check if the "Application Virtualization Management Server" service is running. If not, start it. I asume that this issue is realated to the Database that is not (yet) only when the App-V Management Server service tries to start.
    Recommendation: Place the SQL Server onto another machine that is online before the App-V Box starts 
    Falko
    Monday, November 09, 2009 9:10 PM
    Moderator
  • I've restarted the service.  I have the sql database running on our sql server.  I'm really at a loss of what could be going on here.  I'm getting error code: 4513CDC-19D0682A-0000274D if that is helpful at all to anyone...  Help Please!  this is driving me crazy.
    Tuesday, November 10, 2009 3:23 PM
  • Hello,

    usually the article;
    http://support.microsoft.com/kb/930730

    Pretty much gives you a hint that you have a basic connectivity issue. Now if this is due to network limitations, inproper setup of the server components or perhaps some missed configuration - well thats harder to say since we do not know every detail of your environment.

    It would be nice to know how you setup the environment and if there is anything that is customized at all?
    (GPOs? Server-setup? network-setup?)

    /Znack
    Wednesday, November 11, 2009 11:11 PM
  • Hi,

    Do you have anything more in details in App-V Client's logfile when this error happens? Logfile is called sftlog.txt.

    Have you actually refreshed OSD file into your client after you edited it? And made sure you didn't accidently made XML invalid in it (in which case App-V Client couldn't have replaced cached copy containing reference to 322 port during refresh)?

    /Kalle

    Thursday, November 12, 2009 2:55 PM
    Moderator
  • Below is the latest sftlog.txt file.  The one thing that jumps out at me is this section:

    Attempting Transport Connection
    URL: RTSPS://SERVER:322/DefaultApp.sft
    Host: SERVER:322
    IPAddr: 10.10.1.199
    Error: 19D0682A-0000274D


    I'm not sure where the 322 and rtsps are coming from.  The client is setup at 554, the server should be setup at 554...  Not sure were to check that at though.  I did choose 554 during setup.  The osd file is set to 554 and rtsp...  This is weird...





    [11/12/2009 10:41:13:781 SRVC WRN] {tid=644}
    --------------------------------------------------------
    Initialized client log (C:\Documents and Settings\All Users\Application Data\Microsoft\Application Virtualization Client\sftlog.txt)


    [11/12/2009 10:41:14:343 ???? INF] {tid=644}
    App-V filter loaded

    [11/12/2009 10:41:14:562 VSCM INF] {tid=644}
    Starting Virtual Service Control Manager.


    [11/12/2009 10:41:16:406 JGSW INF] {tid=644}
    The Application Virtualization file system was initialized successfully.


    [11/12/2009 10:41:17:671 INTF WRN] {tid=644}
    The Application Virtualization Client Core initialized correctly.
    Installed Product:
    Microsoft Application Virtualization Desktop Client
    Version: 4.5.1.15580
    Install Path: C:\Program Files\Microsoft Application Virtualization Client
    Global Data Directory: C:\Documents and Settings\All Users\Documents\
    Machine Name:
    5-APPV-TEST
    Operating System: Windows XP Professional 32-bit Service Pack 2.0 Build 2600
    OSD Command: "C:\Program Files\Microsoft Application Virtualization Client\sfttray.exe" "%1" %*


    [11/12/2009 10:41:17:734 SRVC INF] {tid=644}
    ---- The Application Virtualization Client Service version 4.5.1.15580 has started ----


    [11/12/2009 10:44:29:031 MIME ERR] {tid=ED0:usr=test.appv}
    Failure on Desktop Configuration Server request to URL {rtsp://server.domain.edu:554/} with header {Host: server.domain.edu
    Content-Type: text/xml
    } (rc 19D06A0A-10000004).


    [11/12/2009 10:46:01:604 AMGR WRN] {tid=674}
    Attempting Transport Connection
    URL: RTSPS://SERVER:322/DefaultApp.sft
    Host: SERVER:322
    IPAddr: 10.10.1.199
    Error: 19D0682A-0000274D


    [11/12/2009 10:46:15:763 AMGR WRN] {tid=674}
    Attempting Transport Connection
    URL: RTSPS://SERVER:322/DefaultApp.sft
    Host: SERVER:322
    IPAddr: 10.10.1.199
    Error: 19D0682A-0000274D


    [11/12/2009 10:46:30:984 AMGR WRN] {tid=674}
    Attempting Transport Connection
    URL: RTSPS://SERVER:322/DefaultApp.sft
    Host: SERVER:322
    IPAddr: 10.10.1.199
    Error: 19D0682A-0000274D


    [11/12/2009 10:46:31:281 JGSW ERR] {hap=3:app=DefaultApp MFC Application 1.0.0.1:tid=8A0:usr=test.appv}
    The Application Virtualization Client could not connect to stream URL 'RTSPS://SERVER:322/DefaultApp.sft' (rc 19D0682A-0000274D, original rc 19D0682A-0000274D).


    [11/12/2009 10:46:31:327 SWAP ERR] {hap=3:app=DefaultApp MFC Application 1.0.0.1:tid=8A0:usr=test.appv}
    The client was unable to connect to an Application Virtualization Server (rc 19D0682A-0000274D)


    [11/12/2009 10:46:31:452 TRAY ERR] {tid=CD4:usr=test.appv}
    The Application Virtualization Client could not launch DefaultApp MFC Application 1.0.0.1.

    No connection could be made because the target machine actively refused it.


    Error code: 4513CDC-19D0682A-0000274D

     

    Thursday, November 12, 2009 4:21 PM
  • Does the "Default Application" appear on the clien't machine (or has it been there from an older, upgraded client installation)?

    It looks like either you are trying to Launch the DefaultApp manually or the client news (from an older installation) that there should be such an application. (I tend to the first version).

    About the RTSPS/332 thing: On the Server, you have your "content" folder and there the "DefaultApp.osd" is located. You may open it and find the CODEBAS HREF element. There you can modify RTSPS to RTSP and 332 to 554.That at least should fix the RSTPS stuff.

    However, this does not explain the 0A-10000004 error.


    Falko
    Thursday, November 12, 2009 4:32 PM
    Moderator
  • the osd in the content folder is already set to:

    <CODEBASE HREF="RTSP://SERVER:554/DefaultApp.sft" GUID="4F361562-D469-41D8-B6EF-D50538FDB202" PARAMETERS="" FILENAME="defapp\DefaultApp.exe" SYSGUARDFILE="defapp\osguard.cp" SIZE="4720348"/>


    I'm not sure where that log file is getting to look for RTSPS and 332....

    EDIT

    Forgot to answer the first question.  The default app is from this install.  It's a new machine, and it didnt show up until I setup the server and installed the client.  I also have paint.net on the server.  its publishing the app.  The icon shows, but it will not launch either...
    • Edited by pinchy11 Thursday, November 12, 2009 5:13 PM
    Thursday, November 12, 2009 5:07 PM
  • I really appreciate everyone's help.  This is quite the headache for me. 
    Thursday, November 12, 2009 5:08 PM
  • Ok,

    You can find out the location of the logfile by opening up App-V Client Management Console, taking Properties from the root node ("Application Virtualization (local)") and examining Location -field for Logging -section (on top).

    While you're at the console, go to Applications -node and take properties from one of the apps over there (DefaultApp for instance). Go to Package -tab in screen that opens, what does the "Package URL" -field says?

    There's certainly something wrong with your setup if that other app (paint.net) is not streaming either (but is showing up)..

    btw, have you verified - from the central management console - that package relative paths for all your published packages points to correct subdirectory under content -directory?

    /Kalle
    Thursday, November 12, 2009 8:15 PM
    Moderator

  • While you're at the console, go to Applications -node and take properties from one of the apps over there (DefaultApp for instance). Go to Package -tab in screen that opens, what does the "Package URL" -field says?



    btw, have you verified - from the central management console - that package relative paths for all your published packages points to correct subdirectory under content -directory?




    I checked the default app properties and the source on the main properties window shows the rtsp with 554, but under the package URL it shows the RTSPS 322.  Where is that coming from?


    Are you talking about the osd path under the app properties?
    Thursday, November 12, 2009 8:25 PM
  • I checked the default app properties and the source on the main properties window shows the rtsp with 554, but under the package URL it shows the RTSPS 322.  Where is that coming from?


    Are you talking about the osd path under the app properties?


    It is coming from the OSD that client has. For some reason the client has not refreshed updated OSD correctly and that's why it still tries to use RTPSP protocol. For knowing why this has happened, client's logfile likely contains more information.

    Never mind the relative path (it's under Packages -node), it seems that the problem is related to OSD refreshing going through.

    /Kalle
    Friday, November 13, 2009 7:15 AM
    Moderator
  • I can post the whole log file, but it will probably be pretty big.  would that be helpful?
    Friday, November 13, 2009 1:21 PM
  • It'll be enough if you'd post the "last lines" of your log file:

    - log off from your client machine, wait some miniutes
    - log on to the client machine, note the time
    - copy the last lines that occured after you logged on again and post them

    Falko
    Wednesday, November 18, 2009 6:13 PM
    Moderator
  • I have no explanation for this, but the default app started working.  Turned my test machine off, let it sit for a half hour, turned it back on, and now it works.  Makes no sense at all, but I'll take what I can get.
    Thursday, November 19, 2009 3:08 PM
  • When we manually update the *.osd for %SFT_SOFTGRIDSERVER%:322, I have noticed delays between when we refresh in client MMC and when the 'Package URL' information displays correctly even when the right *.osd is downloaded to the client lot sooner. Until the 'Package URL' shows up correctly in the client, streaming will not be successful. So your issue was not completely random :-)
    Thursday, January 14, 2010 7:40 PM