locked
AppV 4.5 stopping listening on port 554, requires server reboot RRS feed

  • Question

  • Hi.

    We are currently running APP-V 4.5 SP2 HF03 Oct 2013 4.5.3.20121 , which is the latest version of AppV 4.5 released.

    Approx once every 4-5 days the AppV server will stop responding to clients on port 554, the AppVirtServer service is still showing as running, however trying to restart this service fails.

    The SFT-Server.log shows an entry of...

    12220 3796 SW_DispatchingService::Open - - - - 1 44867 "Failed to open port: [554]."
    12220 3796 SW_SystemDispatcher::ConfigureProtocol - - - - 1 41505 "Failed to initialize RTSP."
    12220 3796 SW_SystemDispatcher::init - - - - 1 44871 "Unable to configure protocol on ports for server ID: [1].

    I have read other threads about the "phantom process" and it holding on to port 554, and that seems to be the issue that we are experiencing, however the advice is to apply all the hotfixes, which we have, and the issue is still occurring, forcing a reboot of a live server during the working day that many users rely on.

    The server is fully up to date with Windows Updates, 2008 R2 Enterprise. all patches, firmware etc have been updated, and the issue still occurs, the server has 96Gb of RAM and is not showing using anywhere near all that.

    Any suggestions as to what could be causing the AppV service to hang and stop processing requests?

    Thanks

    Andrew Haagensen

    Monday, September 8, 2014 2:45 PM

Answers

  • Hello,

    Oh, I didn't know you tweaked that already. Well, follow the generic performance suggestions and if that doesn't resolve anything you can open a ticket with MS.

    http://madvirtualizer.wordpress.com/2014/07/20/app-v-4-factors-that-can-cause-performance-issues-with-app-v-4-x-servers/


    Nicke Källén | The Knack| Twitter: @Znackattack

    Friday, September 19, 2014 2:55 PM

All replies

  • Well, apart from booting the server (or: restarting the App-V Management service) in off-peak hours one item could be to check if the server really would use that amount of RAM. I don't have a console here, but I think either an advanced property of the server group or individual servers has a value that controls how much RAM the App-V server may use.

    How many users and how many applications do you have (or: how many packages are in use at the same time)?


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Tuesday, September 9, 2014 2:39 PM
    Moderator
  • Hi,

    Thanks for the link to the article, I have checked the values in the database as referenced by that article, and the server has the higher values for all the settings and thus should not have the issues described.

    We have around 150 users currently connected to the AppV at the moment. the problem does seem to have become more frequent as we have pushed up the use of AppV to our users.

    Thanks

    Friday, September 19, 2014 10:15 AM
  • Hello,

    I can't find the original article that I wanted to locate, however see this one;

    http://www.virtualizationadmin.com/articles-tutorials/application-virtualization-articles/installing-microsoft-application-virtualization-part1.html

    Review the suggestion for Max Memory and align it with your configuration. 


    Nicke Källén | The Knack| Twitter: @Znackattack

    Friday, September 19, 2014 12:15 PM
  • Hi.

    We raised the memory allocation up to 3.5Gig , it hasn't made any difference to it crashing from when it was at its default of 512Mb. We didn't allocate it any more due to it been a 32 bit program so didn't think it would take more than 4Gig anyway.

    Thanks

    Andrew

    Friday, September 19, 2014 12:50 PM
  • Hello,

    Oh, I didn't know you tweaked that already. Well, follow the generic performance suggestions and if that doesn't resolve anything you can open a ticket with MS.

    http://madvirtualizer.wordpress.com/2014/07/20/app-v-4-factors-that-can-cause-performance-issues-with-app-v-4-x-servers/


    Nicke Källén | The Knack| Twitter: @Znackattack

    Friday, September 19, 2014 2:55 PM
  • What is happening is there is either a crash or hang triggering a reset and the restart cannot occur due to a hung or dead handle to Port 554. The next time your server gets in that state, can you run a netstat -ano and see if a process tied to sghwdsptr.exe is still listening on that port. Usually it is a hung dispatcher or its zombie which is why a restart will not work but a reboot. If you do find the process still active, you could try killing the process to see if you can restart without rebooting.

    With regards to how it gets into this state - I would follow Nicke's advice with regards to the blog but also remember that RTSP (due to its ephemeral port usage) has a finite limitation. How many clients are checking in with this management server? Also what are the average number of *applications* not packages being used by each one?


    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    Wednesday, November 26, 2014 6:15 PM