Tuesday, February 28, 2012

Neuron: Sharepoint Slow via UNC

Microsoft's Sharepoint can be accessed by a web browser, or via a UNC path as if it is a file server.  We store a lot of documentation on Sharepoint and I find it easiest to manage via UNC path.  Lately I have noticed that my access to the UNC path could take almost a minute.  After digging around a bit, I found that this is a known issue with Windows 7.  Going to Internet Explorer's properties (even if you don't use IE as your browser) and shutting off automatic proxy detection will speed things back up.


Tuesday, February 21, 2012

Neuron: Lan Settings in Internet Explorer Disabled

Today my colleague and I ran across two vendor supplied machines running IE 6.0 (we're not supposed to update them) that we needed to get connected to the Internet for the vendor's support.  Our proxy server, Ironport WSA, has an issue when used transparently with IE 6.0 that requires you to explicitly configure it as the proxy server.  Unfortunately the vendor had disabled access to the LAN Settings even to the Administrator login.

Thankfully, you can't disable the registry.  There are two ways for these settings to be disabled.  The first is as an all users setting and the other is per user.

To enable the settings if done for all users open regedit and go to:
HKLM\Software\Policies\Microsoft\Internet Explorer\Control Panel
In that key will be two values, Proxy and Connection Settings.  Set both to 0 to enable the settings.

The per user setting is in a similar path in the user hive.
HKCU\Software\Policies\Microsoft\Internet Explorer\Restrictions
Likewise the keys need changed to 0.

Friday, February 10, 2012

Hey Window! You Make a Better Door Than You Do a Window.

Over the past two months, I have been battling with a Cisco Aironet 1310 wireless bridge between our main building and a physician's office that we rent across the street.  This physician's office is one building out of a cluster of 15 in a "Doctor's Park".

A few years ago when we put in this link, we were the only wireless in the area.  Within the last 6 months several of the physician's offices and a neighboring nursing home have added wireless infrastructure.

When our problems started, I noticed that our signal strength had gone from an average of -69dBm to -82dBm and our signal to noise ratio was around 10 dBm.  My first thought was obstruction having recently had a different link knocked out by a new HVAC project on the roof of one of buildings interfering too much with the Fresnel zone of another link.  I went up to where the radio was on the main building and took a look.  Nothing new was in the line of site.

Having ruled out the obvious, I fired up the Cisco Spectrum Expert on my laptop and sat up near the radio.  Almost immediately I saw something that wasn't quite right.  All of my APs and bridges are set to use channels 1, 6, or 11.  On the laptop though I was seeing active APs on channels 3 and 8.  Of course since the 2.4Ghz channels overlap, this was causing cross channel interference on all three of the channels that my bridge was configured to be able to use.  As I looked more closely at the Cisco Spectrum Expert information I found the SSIDs associated with these interfering APs.  This is where I got a break, I recognized one of the SSIDs as being from another healthcare entity from another town.  I went back to looking outside and thinking where this might be coming from.  Eureka, one of the physician's offices had a new sign out front with the other entity's logo.  Thankfully the network engineers on their side were gracious enough to reconfigure their stand alone APs to use channels 1 and 11 leaving me 6 for my bridge.

You're probably asking, what does this have to do with a window being a door?  Well yesterday after having resolved our bridge issues for almost a month by my detective work, the problem came back.  This time though, I couldn't find any interference.   Instead, the screen showed something on channel 6 with a very high duty cycle.  I confirmed it was my bridge that was on channel 6.  This puzzled me so I drove over to the far end of the bridge to see if something was amiss there.  I walked up to the radio with my laptop and saw the same type of high duty cycle, but again no interference.

As I did a visual sweep of the room I saw that the window in front of the AP (I know this isn't ideal, but we rent the building.) was partially open such that the metal frame of the window was just about centered in front of the radio.  I asked the clinician whose office it was how long the window had been open.  They told me it had been open for about 2 hours... exactly the amount of time that the bridge had been having problems.  I promptly closed the window and presto the signal strength went back to normal and the duty cycle returned to normal as well.  Once again, the network was undone by the Human Network.

Tuesday, February 7, 2012

Telephony Basics Pt 5

Okay, so now that we have a phone line interconnected from the PBX to the IDF(s) and then to the end user, how do we troubleshoot it if it doesn't work?  My methodology is to work from the MDF out.  I have two tools I use depending on which type of phone I am troubleshooting.

Butt Set
For an analog phone or fax, I use a traditional butt set.  A butt set is a ruggedized telephone handset with a set of clip leads that are used to clip on to a 66 block or other terminal.  Because the metal part of a 110 block is hidden, a special adapter has to be purchased to use a butt set with a 110 block.  If you don't have the adapter, you can remove the jumper and then use a spare piece of jumper wire to punch down to the block and then connect the jumper wires to the butt set clips.  At each step from the MDF out I will hook up the butt set and see if the line works.  Wherever it stops working helps me isolate the problem.  Generally for me it usually ends up being that I have a loose jumper wire, or I punched the jumper down on the wrong terminals.

If the line in question is a "digital" line, the standard butt set won't work.  What I do in that case is I take a RJ-45 jack and wire pins 4 and 5 to a jumper cable.  I then punch down the jumper cable to the points along the path and use the same model phone as the line is configured for to test the line.  It's a bit more cumbersome, but it gets the job done.

This concludes my series on basic telephony and I hope it has been useful to other router jockeys out there that have been put in the situation of learning telephony too.