Outlook VERY slow to send attachments when connected to one network - fine on others

This one is really annoying so thought I'd seek some outside input in case I have missed something.

I have a client who have an office where the network is managed by the building, they have a switch in the ceiling which presumably has it's own VLAN for that office and they are charged for the bandwidth they require (extortionate rates but that's neither here nor there).

They have an issue where they try to send an attachment in Outlook and it fails, I found that if I were to send a tiny attachment (50Kb) then it would send after a couple of minutes so it's able to send them but is incredibly slow. They have a 5Mb symmetrical connection and the testing was done with only one PC turned on so they have more than enough bandwidth for such small attachments. I have spoken to the building IT manager and their external IT company that set it all up but they are being less than helpful, they won't give me access to the switch to monitor stats or adjust the config and aren't willing to spend their own time on diagnosing either.

To rule out other possibilities we have changed one variable at a time:
Tried same computer, exchange account but using the rooms WiFi rather than wired - same issue
Tried different laptop on the same network (wired and WiFi) with same exchange account - same issue
Tried the laptop on their home network with the same exchange account - practically perfect

So the above should have ruled out the PC hardware, software and exchange account so we are back to where we began on the LAN. Seeing as we have enough bandwidth is it possible that any QoS may be affecting the data being sent by Outlook? The office had a problem with dropped packets on VoIP calls, I believe the other IT company worked setting up QoS, I have asked the client for a timeline of the issues.

I need to check but I believe if they use Outlook online they are able to send attachments fine, just thinking out loud here but if using Outlook Web Access would an attachment be uploaded over HTTP and then sent on from the mailserver but if from outlook it would use SMTP? I wonder if SMTP has somehow been deprioritised.

Any thoughts welcomed, I'm sure I will have to go back to the building management but the only was they will do anything is if I am assertive and I don' want to find out I overlooked something and it's not their fault!

Cheers

Rather than SMTP, I believe Exchange/Outlook prefers to use it's own protocol (EAS or MAPI or something like that).

Sorry my memory is hazy as it's been a long time since I did this stuff but I'm thinking along these lines...…

Take in a managed switch that can do port mirroring and your own pc/laptop with wireshark setup.

Now lets say you have an 8 port switch. Stick cable from office lan into any port, and for example, put one of the VOIP phones on port 1, and setup switch to mirror port 1 to port 2.

Now with your laptop you should be able to observe traffic to/from the phone. Make a couple of test calls and you should be able to figure out the DSCP (QoS) settings in use for VOIP.

Now unplug the phone from port 1 and plug your client's machine for testing into port 1.

Run wireshark and observe what happens when you try to send the large email (probably heaps of TCP retries).

Now manually set QoS on the test PC NIC (using same settings as the phone) and redo the test. If it all behaves nicely now you know QoS is throttling your email traffic.

This all assumes the phones and desktops are all on the same lan/vlan, and QoS is using Diffserv.

Or another method, we are both assuming QoS has been setup to prioritise VOIP and this is playing havoc with emails. If you can have sole use of the network again, try other protocols. Any way you can test bandwidth to prove bandwidth the office is receiving is nowhere near what has been sold to your client (and the key point - that a significant amount of your client's traffic is being rejected by the building manager's equipment). Once you have good proof of this, make a nice bill, and get your client to forward this to their building manager with a notice that internet must be fixed at their expense, the quicker this is resolved, the lower the claim will be for breach of contract (unless contract specifies it is a contended/restricted service in which case they are shafted and might as well look at getting their own internet).

Or you could just play naughty and try to make all your client's traffic get prioritised as if it was VOIP. If it's Diffserv that should be a piece of cake. I've seen some implementations of VOIP that prioritise certain ports, just bodge the settings at the client end, then at your end setup a mail proxy and setup your router to port forward the traffic to your proxy on the correct port.

Yes you're right, Exchange has its own protocols, my mistake!

Thanks for the tips, I have a smart 8 port switch that I'm sure supports mirroring so will give that a shot and let you know :)

An update on this one, finally cracked it and lo and behold it was caused by the buildings network as I originally suspected. Due to the building management and the external teams refusal to even consider there was an issue/conflict with their network I troubleshooted until I was absolutely sure it was the buildings network at fault.

I found that the client used Citrix to connect to remote applications so I tested my exchange account on their LAN which worked fine and indicated it was only the traffic being sent over the VPN that was affected. I went back to the building management with this evidence and they informed me that they have a UTM device with policies - this was the first time the had ever told me about this. I suggested that it was conflicting and after a bit of back and forth got them to agree to turn off some security policies one-by-one on the VLAN today and the issues have completely disappeared!