So you have your SoftGrid Virtual Application Server (VAS) installed, your applications sequenced and your clients deployed, but now you find that some or all clients fail to add the appropriate icons or stream a virtual app. You’re anxious to troubleshoot the problem but where do you start? Obviously there are log files you’ll want to read and error messages you’ll want to research in the Microsoft Knowledge Base, but what if none of that pans out? Well, if you understand what SoftGrid does on the wire then you’ll be a step ahead of the rest. That’s what leads us to today’s topic, exploring SoftGrid with Network Monitor.
Disclaimer: My goal here is to explain a concept, specifically in the context of a default SoftGrid installation. Certain technical details will be skipped and some degree of SoftGrid and packet sniffer proficiency is assumed.
As a side note, if you haven’t used the new Network Monitor 3.x then I highly recommend you give it a try. I was one of those who cut my teeth using NetMon 1.x and 2.x but then moved on to other more powerful tools such as Ethereal. Sure, I’m probably a little biased, but after test driving the newest version of NetMon I can say that this is now my unquestioned tool of choice. You can download it for free here plus there’s a great NetMon blog here.
Now on with the show.
Part 1 – DC Refresh
So first of all, what is DC Refresh? DC Refresh is the process that a SoftGrid client goes through (by default on logon) to get the list of apps it is allowed to run. The client also uses this time to populate the host OS with the icons for those apps so they can be accessed by the user. So let’s fire up Network Monitor and see what this looks like:
In our example above, the client (220.127.116.11) first syncs with whatever VAS it is configured to use (18.104.22.168 in our case) using RTSP (port 554). If you’re troubleshooting a problem and you see this fail, either because there is no response from the server or the server resets the connection, I tend to start thinking:
1. Is the SoftGrid Virtual Application Server service running? Are you sure?
2. Is a firewall somewhere blocking port 554?
3. Is there some other service running on the server that is preventing the SoftGrid Virtual Application Server service from listening on 554?
Once we sync over 554 the client will request the list of apps it is allowed to run:
In frame 5 we see the client send an RTSP GET_PARAMETER request to the server, then in frames 6 and 7 we see the server respond. If you look inside these packets you can actually see the list of app names, the paths to the corresponding OSD files, plus the path to the icons for each app. Mine looked something like this:
< APP NAME=”Foxit Reader” VERSION=”2.0.2007.1606″ OSD=”\\jcwin2k3vm\content\Foxit\Foxit Reader 2.0.2007.1606.osd” ICON=”\\jcwin2k3vm\content\Foxit\Foxit Icons\Foxit Reader 2.0.2007.1606.ico”>….<SHORTCUTLIST>..<SHORTCUT ..DISPLAY=”Foxit Reader” LOCATION=”%CSIDL_APPDATA%\Microsoft\Internet Explorer\Quick Launch” ..ICON=”\\jcwin2k3vm\content\Foxit\Foxit Icons\Foxit Reader 2.0.2007.1606.ico” />..<SHORTCUT ..DISPLAY=”Foxit Reader” LOCATION=”%CSIDL_DESKTOPDIRECTORY%” ..ICON=”\\jcwin2k3vm\content\Foxit\Foxit Icons\Foxit Reader 2.0.2007.1606.ico” />..<SHORTCUT ..DISPLAY=”Foxit Reader” LOCATION=”%CSIDL_PROGRAMS%\Foxit Reader” ..ICON=”\\jcwin2k3vm\content\Foxit\Foxit Icons\Foxit Reader 2.0.2007.1606.ico” />..</SHORTCUTLIST>….<TYPELIST>..<FILETYPE EXTENSION=”pdf” PROGID=”FoxitReader.Document” CONTENTTYPE=”application/pdf” PERCEIVEDTYPE=””><PROGID ID=”FoxitReader.Document” FRIENDLYNAME=”PDF Document” EDITFLAGS=”65536″>…<ICON>\\jcwin2k3vm\content\Foxit\Foxit Icons\PDF Document.ico</ICON>….<SHELLCOMMANDLIST >..<SHELLCOMMAND NAME=”open” FRIENDLYNAME=”open” PARAMS=”"%1"”>.
The client uses this information to find the icons and the OSD files for all of the apps it has permission to run. This information also tells the client where these icons should be placed (e.g. on the Start menu, under Program Files, etc.). Now that the client knows where the OSDs and icons are it has to go retrieve them. Using the information obtained in packets 7 and 8, the client then connects to our content share (where the VAS told us to go) using a garden variety SMB connection:
Looking at frames 8, 9 and 10 above we see our three way handshake over port 445. You might also see a sync request using NetBIOS over TCP/IP (port 139) but I cut those out in our example. If you see failures here you’re pretty much looking at a standard file sharing type issue so the same troubleshooting steps would apply. Next we setup our SMB session:
The text may be kind of small but basically what we’re doing is this:
1. In frames 13-16 we’re reading the OSD for our app, in this case Foxit Reader.
2. In frames 17-19 we’re reading the ICO (the icon file) for Foxit.
3. In frames 20-22 we’re reading the FTA icon that we’ll use for any PDF documents the user might have.
If I see failures here I tend to think: Is my path correct? Do the proper files exist? If not, where are they? Lastly, once we get our OSDs and icons we close the connection:
Now I know that there were a lot of packets that I skipped over for the sake of brevity but to summarize this is what we do:
1. The client connects to the server using RTSP (port 554) to find out what apps it has rights to as well as where to go to find the OSD’s and icon files.
2. The client makes an SMB connection to the location specified in the previous step in order to download the OSD’s and icon files.
3. The client uses the information obtained in steps 1 and 2 to create the application shortcuts for the user in the designated locations.
Here’s my highly modified trace of the process one more time:
Hopefully this will give you a better idea of what the SoftGrid client does when it performs a DC Refresh and will help you troubleshoot these kinds of problems should you encounter them. In part 2 we’ll take a look at what happens when a user actually double-clicks on one of those icons and runs an app. Until then, happy sequencing!