• Stack Theory of Troubleshooting

    by  • 2013/04/29 • Tech • 0 Comments

    OSI Model

    OSI Model

    Back in 2001, when I was learning about networking, my class was introduced to the OSI Model. The only reason I paid attention to the model at the time was because it was made clear it would be on the Network+ test.

    However, the 7 layer stack image stayed with me and over the years I started to use it as the foundation of a troubleshooting model.

    I doubt this is novel or unique, but I don’t recall reading about it anywhere and over the years I’ve spoken to colleagues and clients about this and it has generally been well received as helpful.

    When I’m working on an issue I try to identify what layer of the stack the issue would be on. I do this by isolating variables at each layer and testing alternatives.

    The trouble with this stack model is that over the years it has gotten more and more layers.

    Here is roughly what I consider the stack for a XenApp server.


    XenApp Stack

    XenApp Stack

    8 layers without getting too complicated. (User Profile can be split up into more layers in complex environments and using Provisioning Services or Application Virtualization will add more layers too.)

    And that is only the XenApp server, there is still the client end to consider.

    But how is this practical?

    Let’s go through a couple scenarios…

    First a Citrix example, followed by an Outlook example – for the non-Citrix admin.

    Citrix Application Issues.

    A client was having issues getting one particular application to work in their environment. It didn’t work on their test server so they couldn’t roll it into production. All the other applications on the test server were working. The application wouldn’t even open.
    From those two details we could guess the issue was above the Windows Server layer in the stack. After trying a few things to get the application to launch (Run as Admin, change EXE launch parameters, re-install, etc.), we thought the application might not actually be the issue, we could install it on non-XenApp servers and get it to work. During one test session where I had connected to the server via Remote Desktop Client (instead of the Citrix desktop) the program worked just fine. This allowed me to effectively bypass the XenApp layer. Since the application worked this way I knew where to focus my efforts.

    Outlook Performance.

    A client was migrating from a CRM based mail system to Exchange and Outlook.
    As the roll out progressed we got a lot of complaints from the users that Outlook was freezing. Exchange was hosted by a third party, off premise.
    Not all users would have the issue, those that had Outlook freeze typically saw it happen multiple times a day, 10 – 20 times in extreme cases.
    After going through the hosted Exchange provider’s troubleshooting steps we were no further ahead, it appeared the issue wasn’t caused by the server.
    The computers were only a few years old and when they were rolled out had been deployed from a standard image. We couldn’t isolate any differences between the computers to account for why Outlook would freeze for some users but not others. After testing Outlook – starting in safe mode, re-install, new profiles, resetting printing, etc. All that was left was the network layer of the stack.
    They have a chassis switch with all ports running at 1GB, no error lights on the switch, the configuration had been running fine for years. However, we decided to try a different switch, just in case.
    Once we had the new switch cabled up our test users reported the freezing was, at least, dramatically reduced – once or twice a day, instead of 10 -20 time.
    But we couldn’t say the issue was the old switch, because when we were setting up the test switch we had to use longer cables as there wasn’t rack space close enough to the patch panel.
    We moved the, new, longer cables back to the original switch and our test users didn’t notice the change, Outlook was still running fine. It appeared the old cables just weren’t up to the demands of Outlook and Exchange.


    I try to use the Stack model as a cheat sheet, a quick reference for where the problem might be. It helps me when I get stuck, as I have to acknowledge that the issue might be in a different layer so I look elsewhere.

    I hope it will help you too.


    Clint McGuire is a Computer Consultant based out of Vancouver Canada. He specializes in VMware and Storage.

    Leave a Reply

    Your email address will not be published. Required fields are marked *