Skip to main content

Bad Tech Advice, Pt. 1

I had other items to write about, but my fury at having to deal with astonishingly bad tech support, advice, or recommendations is at a boiling point. It's not the inexperience or naivety that bothers me, we all have to start somewhere and some of us still struggle with new technology. It's the fact that these people, or companies, sell themselves as "experts"; after which I have to explain to the client that they would have gotten more from their money by investing in one of the many wonderful business opportunities available in Nigeria.

Case in point:

One of my clients purchased a recorder for their VoIP phone system. These recorders work by capturing traffic on a line, filtering out the non-voice traffic, rebuilding the conversation, and then committing the audio and call information to storage. This particular system (whose unfortunate owner and witless provider shall remain nameless) was sold under the oft-abused title of "Plug-N-Play". Even the clients current infrastructure was evaluated and approved to be compatible by the provider. Needless to say, this was not the case.

The essential problem with the system is that the protocol used by the phones transmits audio information directly from phone to phone (not through the 3COM NBX) when you make an interoffice call. Since the clients switch is only capable of doing one-to-one port mirroring, we can only monitor one port at a time. I selected the NBX port and we were able to successfully record out of office calls, but interoffice messages were still silent.

Although I was 99% sure we simply needed a switch capable of many-to-one port mirroring, I wasn't about to recommend an expensive purchase to a client without some sort of guarantee or official recommendation. After several days of trying to get a clear answer from the provider via email (based in the UK, they have no +1 country code number and the times zones don't really match up anyways), I got sent this little dandy of a message:

As per your latest email, engineering recommends that the best way to fix this is to put all of the phones through a hub (unswitched) and place the uplink into the NBX

Yup. They want me to take dozens of phones and plug them all together on an unswitched hub, complete with collisions. For those not familiar with hubs, they are essentially the senile granddaddy's of switches. A true hub will blindly regenerate the signals from one port and repeat them out ever other port. While this would technically allow us to capture all traffic, it also puts all the phones into a single collision domain and forces them to share bandwidth. So when two phones try to send audio at the same (as is often the case in a busy office), the audio frames stand a good chance of having a collision of James Dean proportions. This is why CSMA/CD was developed, which postpones sending another frame when a collision is detected. Just dandy when you are sending, say, an email that can be delayed a half a second. Not so great when you need to transmit time-sensitive information, like a freaking phone call.


Popular posts from this blog

Outlook Credential Prompt When Opening Exchange 2013 Public Folder

After completing an Exchange 2007 > 2013 migration recently, I was left with one issue that was preventing us from stamping the project as a roaring success and moving on:

Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.

Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.

However, we were in a different boat - Users got the prompt once when they first launchedOutlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.

Repairing Mailbox Corruption in Exchange 2010

I recently got through recovering an SBS 2011 server after Active Directory face-planted in the middle of a workday. When I say recover, I mean I repeated the entire migration, using a cleaned up secondary DC - it was a fun weekend (expect another post about that experience). Although I thought we were in the clear, I got a call from the client about 24 hours after we had verified everything was working. He indicated that his iPhone had suddenly stopped receiving mail in the inbox (calendar, contacts, sent items were still fine) and throws up an error after spinning in circles for a few minutes that it "cannot connect to mail server".

SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.