I'm getting SEVERAL entries in my packet capture that I beleive indicate lost packets. TCP Dup ACK & TCP Retrasmission to be specific. I see there is a problem here, but can someone walk me step by step through identifying what the cause of this is? I'm assuming that somewhere within the capture it will tell me the workstation or piece of equipment that is causing this problem??

Your trace is not indicating lost packets as much as you think - you just got tons of duplicate packets in there, which Wireshark will mark as retransmissions or duplicate ACKs. This is usually caused by spanning multiple source ports or a VLAN. I deduplicated your trace using editcap like this:

Sorry. Packet traces will not tell you where the lost is happening. To do that, you have to capture at multiple capture points - not always practical. Are you seeing FAST RETRANSMISSIONS or just RETRANSMISSIONS? Not all packet losses are equal, some are more damaging than others (in terms of performance). If you can post your trace file somewhere, folks may be able to download it an help you analyze it.

There is an interesting conversation going on between 192.168.1.35 ( sender ) and 192.168.3.54 ( receiver ) where we see a lot of zero window size on the .54 side.
Although we don't have the SYN > SYN/ACK it looks like window scaling is not enabled on the .54 machine. The sender sends 65k of data which the sender ACKs with the large number of ACKs that we see whilst reducing the window but increasing the ACK by 2920 bytes which indicates that the receiver is buffering the data but the application is not consuming it. Given that the time taken for each of these events ( zero window, zero window probe and window update ) can be 1.5 -2s then performance for this particular app will be slow.
If the app can't handle 65k of date then I'm not sure enabling window scaling will help, the sender would just send more data and the receiver would just buffer the now increased window size worth of data until the app can consume it. In this case it looks like application level delay for this particular conversation.

Of course it could be that the sender only sends in 65k chunks, certainly the PSH biit is set on the last packet indicating the sender has no more data to send and it's always set on the last packet at around 65k, we'd need to see the 3 way handshake to find out if WS is on and what it's at. It's still application level delay.